Belajar Software Architect - Performance & Scalability Design

#Pendahuluan

Setelah di episode 10 kalian membangun security architecture — threat model STRIDE, defense in depth, dan zero trust foundation — pada episode ini kita kerjakan quality attribute nomor dua di peta studi kasus kita: performance & scalability, dengan target eksplisit dari episode 5: p99 read ≤ 300 ms dan ketahanan spike 10x saat flash sale.

Performance dan scalability sering dicampuradukkan. Performance tentang kecepatan satu request; scalability tentang kemampuan menahan beban bertambah tanpa redesign. Keduanya dilayani tactics berbeda tapi saling bertumpu — dan keduanya paling murah didesain sejak awal, bukan dioptimalkan setelah insiden.

#Memahami Pola Beban Dulu

Desain dimulai dari karakteristik traffic, bukan teknologi:

Baseline : ~200 rps read-heavy (rasio baca:tulis ≈ 100:1)
Flash sale : pukul 20.00 mingguan → lonjakan 10x dalam <60 detik
Hot spot : produk diskon sama diserbu bersamaan

Tiga sifat ini menentukan semuanya: read-heavy berarti caching adalah senjata utama; lonjakan tajam berarti autoscaling reaktif saja terlambat (instance baru butuh menit untuk siap); hot spot berarti partition key tunggal bisa menjadi bottleneck meski kapasitas total cukup.

#Caching Berlapis

Cache efektif dikelola berlapis — tiap lapis menyaring permintaan agar tak pernah sampai ke database:

Browser cache      → asset statis, API response singkat
CDN                → halaman produk publik, image
App-level (Redis)  → hasil query panas, computed data
DB buffer pool     → hot pages (otomatis)

Prinsip per lapisan:

• CDN — konten public & immutable adalah free win; Cache-Control yang benar menghilangkan mayoritas trafik origin.
• App cache — simpan hasil yang mahal dihitung (harga tampil, stok agregat). Tetapkan TTL sesuai toleransi staleness bisnis — pertanyaan "berapa detik stale boleh?" dari episode 8 dipakai lagi di sini.
• Invalidation — strategi paling aman bukan "hapus tepat waktu", tapi short TTL + event-driven invalidasi: event StockChanged/ProductUpdated dari outbox episode 8 menghapus key relevan.

#Jebakan Cache Populer

#Cache Stampede

Saat key panas kedaluwarsa, ratusan request simultan melewati cache dan menghantam database bersamaan — persis saat flash sale dimulai.

Mitigasi:

Single-flight   → hanya 1 request rebuild, sisanya tunggu hasilnya
Lock + refresh  → kunci per-key, proses lain pakai nilai basi
Probabilistic early refresh → perpanjang TTL acak sebelum expiring

#Thundering Herd

Mirip stampede tetapi lintas service: satu komponen gagal/lambat, seluruh caller retry bersamaan dan menjatuhkannya permanen. Mitigasinya retry dengan exponential backoff + jitter (dibahas penuh di episode 16) plus load shedding di edge.

#Hot Key

Satu key Redis menerima puluhan ribu QPS (produk flash sale) — satu shard cache jenuh padahal cluster lain idle. Mitigasi: replicate key panas ke beberapa node atau cache di-process memory aplikasi untuk key super-panas.

#Strategi Scaling

#Scale Out dengan Statelessness

Horizontal scaling menuntut instance yang saling menggantikan sempurna:

• Session di Redis/JWT, bukan memori process.
• File di object storage, bukan disk lokal.
• Konfigurasi via environment/config server.

Aturan ujinya: kill -9 satu instance acak kapan pun harus nol dampak bagi pengguna.

#Read Scaling vs Write Scaling

Read mudah: replika database, cache, denormalisasi. Write lebih sulit:

Async write    → antrikan non-kritis (view counter, log)
Batching       → gabung tulisan kecil per interval
Sharding       → pecah baris per partition key
CQRS           → pisahkan model tulis & baca (episode 8)

Untuk studi kasus kita: order write saat flash sale ≈ 2 ribu tps peak — PostgreSQL single primary dengan connection pooling sanggup; sharding belum dibayar. Keputusan ini konsisten dengan ADR-0002.

#Autoscaling yang Benar

• Scale pada leading indicator (queue depth, CPU tren), bukan trailing latency yang sudah telanjur naik.
• Pre-scaling terjadwal untuk event diketahui (flash sale pukul 20.00): naikkan kapasitas 15 menit sebelum, turunkan bertahap setelah.
• Selalu ada headroom — aturan praktis: alarm saat utilisasi > 60% karena spike datang lebih cepat dari provisioning.

#Capacity Planning dengan Back-of-the-Envelope

Architect harus bisa menghitung kasar sebelum benchmark. Contoh untuk target kita:

Target        : 2.000 rps checkout, p99 ≤ 800 ms
Per-instance  : 100 rps pada p99 aman (hasil load test)
Instance butuh: 2.000 / 100 = 20 + headroom 50% = 30 pod
DB connection : 30 pod × 20 conn = 600 → wajib pooling (PgBouncer)
Cache         : produk panas ±500 item × 4 KB = trivial;
                fokus pada QPS, bukan ukuran

Angka pastinya datang dari load test, tetapi estimasi ini menentukan bentuk arsitektur lebih awal: pooling wajib, autoscaling target ~30, pre-scale terjadwal.

#Load Testing: Verifikasi, Bukan Harapan

Quality scenario tanpa verifikasi hanyalah harapan. Praktik minimal:

k6 run --vus 200 --duration 5m checkout-load.js
# thresholds di script: p95<800ms, error_rate<0.1%

Jadwalkan tiga jenis: smoke test rutin di staging tiap rilis besar, spike test mensimulasikan lonjakan mendadak 10x, dan soak test mencari kebocoran memori/koneksi di durasi panjang. Hasilnya dibandingkan langsung terhadap response measures episode 5 — gap-nya adalah backlog arsitektur kalian.

#Kesalahan Umum

• Optimizing tanpa profiling — menebak bottleneck biasanya meleset; ukur dulu (APM, flame graph), optimalkan titik terpanas.
• Premature optimization sebaliknya — menunda semua keputusan performa "sampai ada masalah"; struktur yang salah (N+1 by design, sinkron chain panjang) mahal dibongkar kemudian.
• Cache everything — data personal dan sering berubah tidak layak cache; kompleksitas invalidasi melebihi manfaatnya.
• Autoscaling sebagai jimat — scale-out reaktif tidak menolong database tunggal dan tidak cukup cepat untuk spike 60 detik.
• Lupa downstream capacity — men-scale app 10x sementara payment gateway limit 1 ribu tps hanya memindahkan antrean ke tempat yang tak bisa kalian scale.

#Penutup

Inti yang harus dibawa pulang:

• Desain performa mulai dari pola beban: read-heavy → caching; spike tajam → pre-scaling; hot spot → key distribution.
• Caching berlapis CDN → Redis → DB, dengan TTL sadar-staleness dan invalidasi event-driven dari episode 8.
• Kenali jebakan namanya: stampede, thundering herd, hot key — masing-masing punya mitigasi standar.
• Scale horizontal menuntut statelessness; write scaling punya tangga opsi dari async sampai sharding — naiki seperlunya.
• Capacity planning back-of-envelope menentukan bentuk arsitektur; load test realistis yang memverifikasi.
• Studi kasus kini punya rencana kapasitas flash sale konkret: 30 pod pre-scaled, pooling wajib, mitigasi stampede di jalur produk panas.

Di episode 12 selanjutnya kita masuk bab microservices: kapan modular monolith kita benar-benar perlu pecah, cara memotong service boundary, komunikasi antar service, dan saga pattern untuk transaksi lintas mereka. Sampai jumpa!