Belajar Solution Architect - Performance Solution Design

#Pendahuluan

Setelah di episode 15 solusi kalian punya strategi resilience yang diuji — RTO/RPO dari kerugian bisnis, DR bertingkat, backup yang terbukti bisa di-restorasi — kini kita bahas properti yang paling cepat terasa oleh pengguna: performa. Bedanya dengan resilience, masalah performa bukan kejadian langka melainkan tekanan harian: setiap lonjakan trafik, query berat, atau deploy buruk langsung terlihat di latensi.

Mengapa performa adalah urusan arsitektur, bukan sekadar optimasi kode? Karena 10x peningkatan jarang datang dari micro-optimization; ia datang dari keputusan desain — cache di tempat tepat, antrean di titik panas, read replica, atau CDN. Keputusan itu diambil SA jauh sebelum engineer menulis loop pertama.

#Capacity Planning Berbasis Angka

Performa dimulai dari pertanyaan sederhana yang sering dijawab asal: berapa kapasitas yang kita butuhkan? Metodenya harus turun dari requirement (episode 3):

Asumsi bisnis   : 500.000 tiket/bulan, peak sale 50.000 user serentak
Konversi trafik : 50 rb user x 1 request / 3 detik ~= 17.000 req/s puncak
                  (dengan CDN menyerap 70% statis -> origin ~5.000 req/s)
Kapasitas unit  : 1 instance order-service = 250 req/s pada p95 300 ms
Kebutuhan       : 5.000 / 250 = 20 instance + headroom 30% = 26 instance
Database        : 5.000 req/s baca 80% -> read replica x3 + cache hit 90%

Tiga pelajaran dari perhitungan itu:

1. Selalu turunkan dari angka bisnis ke request/s — "50 ribu user" tanpa konversi pola perilaku tidak berarti apa-apa untuk sizing.
2. Headroom wajib (biasanya 30%) — kapasitas tepat 100% artinya insiden saat deviasi pertama.
3. Cache mengubah semua hitungan — hit ratio 90% memotong beban database sepuluh kali; inilah alasan desain cache ditempatkan sebelum sizing (episode 7).

#Performance Budget per Endpoint

Target global ("aplikasi harus cepat") tidak berguna. Yang bekerja adalah budget per jalur, diturunkan dari NFR:

Manfaat budget ini ganda: saat produksi lambat, kalian tahu jalur mana yang bocor dari anggarannya; dan saat ada proposal fitur baru di jalur panas, dampaknya pada budget bisa dinegosiasikan eksplisit (gaya pertukaran episode 11). Tanpa budget, semua diskusi performa berubah menjadi opini.

#Strategi Scaling yang Tepat Sasaran

Tiga sumbu scaling yang harus dipilih sadar-sadar:

• Vertikal — instance lebih besar. Cepat, tanpa ubah aplikasi, tapi ada plafon fisik dan single point of failure.
• Horizontal stateless — tambah instance + load balancer. Standar tier aplikasi; syaratnya state eksternal (session/cache).
• Horizontal stateful — sharding/partisi data. Paling kompleks; lakukan hanya jika replikasi vertikal+horizontal biasa tak lagi cukup.

Plus dua akselerator yang mengurangi beban scaling itu sendiri:

• Pre-warming untuk event terjadwal: sale tiket punya waktu mulai yang diketahui — naikkan kapasitas T-15 menit, jangan tunggu autoscaler bereaksi terlambat (lag provisioning beberapa menit adalah kenyataan).
• Load shedding & prioritas: saat melebihi kapasitas, tolak traffic prioritas rendah (bot scraping, polling) agar checkout tetap dilayani. Lebih baik sebagian user lihat halaman ramai daripada semua user timeout.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 6
  maxReplicas: 40
  metrics:
    - type: PodMonitoringMetric
      podMonitoringMetric:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "250"

Skala min-max dari perhitungan kapasitas tadi (floor 6 ≈ baseline normal, ceiling 40 mencakup peak + headroom) — angka HPA yang punya dasar, bukan default kosong 1..10.

#Menemukan Bottleneck dengan Metode Benar

Sistem lambat selalu punya satu-dua bottleneck dominan. Urutan penyelidikan yang efektif:

1. Ukur dulu, duga belakangan — distributed tracing (OpenTelemetry) menunjukkan persis di hop mana waktu habis; menebak tanpa trace = mengoptimalkan bagian yang salah.
2. Utilization → Saturation → Errors (metode USE) untuk tiap resource: CPU/memori/koneksi DB/I/O — cari yang saturated lebih dulu.
3. Bottleneck klasik berurutan frekuensinya: koneksi database (pool kecil), N+1 queries, sinkronisasi lock, serialisasi JSON besar, DNS/TLS handshake berulang, GC pause.
4. Latency vs throughput trade-off: antrian menambah latency total tapi menaikkan throughput sistem; keputusannya per jalur sesuai budget.

#Load Testing Sebagai Bukti, Bukan Formalitas

Semua angka di atas bermuara ke satu ritual: load test pra-launch dengan skenario realistis:

• Ramp-up menuju target peak (5.000 req/s origin) — temukan titik degradasi.
• Sustained peak 30-60 menit pada level puncak — deteksi memory leak, connection pool exhaustion, backlog queue.
• Spike test — lompatan mendadak dari 500 ke 5.000 req/s mensimulasikan pembukaan sale; ukur recovery time.
• Soak test — durasi jam-jaman level rendah untuk kebocoran pelan.

Metrik keluarannya dibandingkan langsung dengan performance budget: p95/p99 per endpoint, error rate, saturasi tiap komponen. Temuan menjadi backlog perbaikan berprioritas — dan setelah perbaikan, uji ulang hingga budget terpenuhi. Siklus ini juga dijadwalkan ulang tiap perubahan besar arsitektur, bukan sekali seumur proyek.

Satu catatan biaya (episode 9): load test skala penuh menghasilkan tagihan egress dan compute sendiri — jadwalkan di environment yang sama dengan produksi (agar valid), tapi di window yang disepakati dan dengan tagging biaya khusus.

#Penutup

Inti yang harus dibawa pulang:

• Kapasitas dihitung dari angka bisnis → request/s → jumlah unit, dengan headroom; cache mengubah seluruh persamaan sebelum sizing.
• Performance budget per endpoint mengubah diskusi performa dari opini menjadi akuntabilitas terhadap anggaran milidetik.
• Pilih sumbu scaling sadar: vertikal untuk cepat, horizontal stateless sebagai standar, sharding hanya jika benar-benar perlu; pre-warming untuk event terjadwal dan load shedding saat melebihi kapasitas.
• Cari bottleneck dengan tracing dan metode USE — urutan bottleneck umum sudah cukup prediktabel untuk jadi checklist.
• Load test multi-skenario (ramp, sustained, spike, soak) dengan generator open-model adalah bukti bahwa target performa bukan janji.

Di episode 17 selanjutnya kita akan membahas PoC & prototyping — cara membuktikan risiko terbesar desain dengan eksperimen kecil yang timeboxed, menyusun success criteria yang tidak bisa diperdebatkan, serta menjembatani hasil PoC menjadi keputusan arsitektur resmi. Sampai jumpa di episode 17!