Sesi 31 — Membaca Design Doc Seperti Orang Dalam

1. Bayangkan jika —

Kamu baru bergabung ke tim. Di meja sudah ada satu dokumen — arsitektur sistem yang akan diluncurkan tiga minggu lagi. Lima belas menit untuk presentasi. Sisanya tergantung padamu: mana titik yang paling mungkin patah, dan berapa kapasitas yang benar-benar dibutuhkan.

Orang yang membaca design doc seperti perancangnya tahu di mana mencari. Mereka tidak membaca semua bagian sama rata — mereka langsung ke titik tekanan. Dan mereka punya daftar pertanyaan yang sama setiap kali, tidak peduli sistem apa yang ada di hadapan.

2. Apa yang Sebenarnya Terjadi

Apa yang Ada di Design Doc

Design doc yang baik biasanya mengandung: gambaran arsitektur keseluruhan, komponen dan dependensinya, volume trafik yang diharapkan, SLO yang dijanjikan, dan keputusan teknis beserta alasannya.

Yang tidak selalu ada: angka kapasitas yang dihitung dari kebutuhan nyata (bukan tebakan), skenario kegagalan yang sudah diperhitungkan, dan batas beban yang diuji.

Itulah celah yang perlu diisi seorang performance tester.

Cara Membaca: Lima Langkah

1. Baca SLO dahulu. Sebelum memahami arsitektur, pahami janji yang dibuat ke pengguna: availability, latency p99, throughput maksimum. Ini yang menentukan kapan sistem dianggap "lulus."

2. Temukan titik konvergensi trafik. Di diagram mana semua jalur bertemu? Biasanya API Gateway, load balancer utama, atau database primer. Itu kandidat pertama yang akan patah saat beban naik.

3. Hitung kapasitas dari angka bisnis. Bukan dari "server yang kita punya" — dari "transaksi per jam di puncak kampanye" dikali "waktu proses per transaksi" dikali "faktor keamanan."

4. Cari dependensi tersembunyi. Layanan eksternal tanpa SLA, sistem legacy tanpa circuit breaker, database bersama yang tidak ada di diagram karena "sudah ada dari dulu."

5. Periksa observability yang dijanjikan. Bagaimana tim tahu sistem sedang sekarat sebelum pengguna menelepon? Kalau jawabannya "kita lihat di log," maka Sesi 27–30 belum diimplementasikan.

Capacity Planning: Dari Angka Bisnis ke Angka Server

Formula dasar:

Capacity = (Peak TPS × Avg Response Time) / 1000 × Safety Factor

Contoh konkret: - Kampanye flash sale: 50.000 transaksi per jam di puncak = ~14 TPS rata-rata, tapi dengan spike 10× = 140 TPS puncak - Avg response time database: 80ms - Connection yang dibutuhkan: 140 × 0.08 = ~12 koneksi aktif - Dengan safety factor 3× dan connection overhead: butuh pool minimal 40 koneksi - Dengan 100 pod, tiap pod butuh 1 koneksi ke pool — tapi pool total harus bisa melayani 100 × max concurrent per pod

Inilah kenapa "tambah pod" tidak otomatis membantu: kalau database connection pool sudah penuh (Sesi 16), lebih banyak pod hanya berarti lebih banyak yang antri.

Daftar Pertanyaan Baku

Ini adalah checklist yang seorang performance tester bawa ke setiap review design doc:

Kapasitas: - Berapa TPS puncak yang dijanjikan? Dari data apa angka itu berasal? - Apakah sudah ada safety factor? Berapa? - Kalau trafik naik 5× dari prediksi, komponen mana yang pertama kolaps?

Dependensi: - Layanan eksternal apa yang dipanggil? Berapa SLA-nya? - Apakah ada circuit breaker untuk setiap dependensi external? - Database apa yang digunakan? Apakah connection pool sudah dikonfigurasi?

Failover: - Kalau satu zone mati, trafik dialihkan ke mana? Berapa lama? - Apakah health check sudah dikonfigurasi di load balancer? - Apa perilaku sistem saat cache miss 100%? (Sesi 19 — cache stampede)

Observability: - Metrik apa yang dimonitor untuk mendeteksi degradasi lebih awal dari pengguna? - Apakah ada alert untuk p99 latency — bukan hanya availability? - Berapa MTTD dan MTTR target yang sudah diuji?

Uji Beban: - Apakah sudah ada load test sebelum go-live? - Apa skenario chaos yang sudah dijalankan? - Di mana dokumen hasil load test terakhir?

3. Bagaimana Jika Kita Coba...

"Kita percaya saja angka yang sudah ada di dokumen." Angka di design doc sering berasal dari asumsi tiga bulan lalu, sebelum business case berubah. Kapasitas ditulis berdasarkan "kita punya 4 server" — bukan "pengguna kita akan 40.000 per jam." Dokumen adalah titik awal untuk bertanya, bukan jawaban akhir.

"Kita uji kalau sudah hampir go-live." Saat itu, perubahan arsitektur sudah sangat mahal. Pertanyaan kapasitas harus dijawab di fase desain — di situlah menggantinya masih gratis.

4. Nama Resminya

Konsep	Definisi Singkat
Capacity Planning	Menentukan berapa sumber daya yang dibutuhkan untuk melayani beban yang diharapkan dengan margin keamanan
Headroom	Selisih antara kapasitas terinstall dan kapasitas yang sudah terpakai — berapa ruang tersisa sebelum sistem kolaps
Cell-Based Architecture	Membagi infrastruktur ke unit independen (cell) supaya kegagalan dibatasi radiasinya, bukan satu insiden membunuh semuanya
Blast Radius	Seberapa luas dampak kegagalan satu komponen — berapa persen pengguna yang terdampak kalau satu node atau satu zone mati
Peak Factor	Rasio antara trafik puncak dan trafik rata-rata — biasanya 5–20× untuk sistem konsumen
Chaos Engineering	Praktik memperkenalkan kegagalan yang dikendalikan ke sistem produksi untuk memverifikasi bahwa redundansi benar-benar berfungsi

5. Di Dunia Kita

Di sistem yang sudah matang, review design doc adalah momen terpenting seorang performance tester. Karena di sinilah keputusan arsitektur masih bisa diubah dengan murah — sebelum kode ditulis, sebelum infrastruktur dikonfigurasi.

Saat kampanye besar akan datang: review design doc tiga minggu sebelum go-live, temukan bahwa connection pool database dikonfigurasi untuk peak 200 TPS, sementara prediksi bisnis baru bilang 800 TPS. Perubahan konfigurasi: satu jam. Kalau ditemukan satu minggu setelah go-live: insiden, rollback, overtime, postmortem.

6. Lensa Performance Tester

Empat dokumen yang harus kamu minta sebelum bisa mengevaluasi design doc:

Data historis trafik — bukan angka prediksi, tapi angka yang benar-benar pernah terjadi. Dari sini peak factor dihitung, bukan ditebak.
Konfigurasi resource limits saat ini — berapa koneksi database per instans, berapa thread pool aplikasi, berapa memory limit pod.
Hasil load test terakhir — kapan dilakukan, dengan skenario apa, dan apa yang ditemukan.
SLO dokumen resmi — bukan yang "biasanya oke", tapi yang sudah dikomunikasikan ke pengguna dan ada SLA-nya.

Dengan empat dokumen itu, checklist pertanyaan baku di Bagian 2 bisa diisi dengan angka nyata — dan hasilnya bisa menjadi rekomendasi yang bisa ditindaklanjuti.

7. Pertanyaan untuk Level Berikutnya

Level 3 sudah selesai. Kamu sudah tahu cara memecah sistem, cara layanan saling bicara, cara menjaga jalur lalu lintas, cara menahan gelombang beban, dan cara membaca arsitektur yang belum pernah kamu lihat.

Satu pertanyaan yang tersisa: setelah semua layanan itu berjalan, bagaimana kamu tahu bahwa log yang ditulis aplikasi benar-benar sampai ke tempat yang bisa dibaca saat jam tiga pagi — dan tidak diam-diam hilang saat pod yang menulis log itu mati?

Itulah yang dimulai di Sesi 32: Pipa yang Tak Terlihat — Fluent Bit, Fluentd, dan Sidecar Log Collector.