Reference · System Design · Kerangka 5 langkah
Kerangka 5 langkah
Ringkasan satu halaman untuk dibaca ulang menjelang interview. Dari Lesson 0027, dengan pola kalimat dari 0025. Latihan penuhnya: mock 0036.
Lima langkah dan alokasi 45 menit
1 · Requirement→
2 · Estimasi→
3 · API + data model→
4 · High-level (v1)→
5 · Deep dive
| Langkah | Yang ditulis di papan | Waktu |
|---|---|---|
| 1. Klarifikasi requirement | 3–5 functional requirement ("user bisa …"); non-functional dalam angka: DAU, latency, availability, consistency | ±5 menit |
| 2. Estimasi | QPS rata-rata dan puncak, rasio baca:tulis, storage beberapa tahun, bandwidth bila relevan | ±5 menit |
| 3. API + data model | 2–4 endpoint inti (method, path, input, output); tabel/entitas utama dengan key | ±7 menit |
| 4. High-level design | Desain v1 paling sederhana yang memenuhi angka langkah 2; telusuri satu request tulis dan satu request baca | ±13 menit |
| 5. Deep dive, bottleneck, trade-off | Bottleneck pertama dari angka, komponen yang menyelesaikannya, biaya dan risikonya, evolusi v2 | ±15 menit |
5 + 5 + 7 + 13 + 15 = 45 menit adalah konvensi track ini, bukan aturan resmi. Kalau interviewer mengarahkan ke bagian tertentu, ikuti; kerangka adalah peta, bukan naskah.
Pertanyaan klarifikasi standar (langkah 1)
- Functional: fitur inti apa (pilih 3–5, sisanya "di luar scope")? User-nya manusia lewat aplikasi atau service lain lewat API?
- Skala: berapa DAU? Berapa aksi per user per hari? Rasio baca:tulis?
- Latency: target p99 untuk operasi terpenting? Non-functional requirement baru berguna kalau terukur: SLI adalah "a carefully defined quantitative measure of some aspect of the level of service". [1]
- Availability: berapa "sembilan"? 99,9% = ±43,2 menit downtime per bulan; 99,99% = ±4,32 menit. [2]
- Consistency: boleh telat terlihat beberapa detik (eventual), atau harus langsung (strong)?
- Data: berapa lama disimpan? Ukuran satu item? Ada data sensitif?
Kalau interviewer menjawab "terserah Anda": ajukan asumsi dengan angka, lalu minta persetujuan.
Langkah 4 dan 5: v1 dulu, komponen dibenarkan angka
- v1 sering cukup satu app server (atau dua di belakang load balancer demi availability) dan satu database. Tim harus "push back when accidental complexity is introduced". [3]
- Setiap komponen tambahan memakai satu pola kalimat:
"Untuk skala ini cukup X. Kalau metrik Y melewati Z, langkah berikutnya W, dengan biaya B." - Contoh: "Untuk 1.000 QPS baca, satu PostgreSQL dengan index cukup. Kalau p99 query baca melewati 50 ms di jam puncak, saya tambah cache; biayanya stale data dan satu komponen lagi."
- Komponen tanpa angka (Kafka "untuk jaga-jaga", microservices untuk 1.000 user) = over-engineering, dinilai negatif.
Jebakan dan perbaikan
| Jebakan | Perbaikan |
|---|---|
| Langsung menggambar diagram akhir dengan 10 kotak | Gambar v1 dulu, lalu evolusi v2 dengan alasan per kotak |
| Estimasi dihitung lalu dilupakan | Rujuk angka langkah 2 setiap kali menambah komponen |
| Deep dive di topik favorit, bukan bottleneck | Pilih bottleneck terbesar menurut angka, atau tanya interviewer |
| Satu pilihan tanpa trade-off | Selalu sebut biaya: latency, konsistensi, biaya operasional, risiko |
Lima studi kasus dalam satu baris
| Soal | Angka kunci | Keputusan deep dive |
|---|---|---|
| URL shortener | ±10 QPS tulis, ±1.000 baca (100:1), ±1 TB / 5 tahun | Base62 dari sequence; 302 vs 301; cache-aside setelah p99 diukur |
| Rate limiter | Limit konsisten di banyak instance | Counter di Redis (INCR atomik), 429 + Retry-After |
| Notification | Pengiriman lambat dan pihak ketiga tidak stabil | Queue per channel, retry + backoff, idempotency, DLQ |
| News feed (B) | Read-heavy; akun besar | Fan-out on read di v1 → hybrid fan-out on write |
| Chat (B) | Jutaan koneksi bersamaan | WebSocket stateful, presence dengan TTL, seq per percakapan |
[1] Google SRE Book, bab 4: Service Level Objectives · [2] Google SRE Book, Appendix A: Availability Table · [3] Google SRE Book, bab 9: Simplicity
Cheat sheet lain: angka dan estimasi · trade-off komponen · Indeks