Lesson 0027 · System Design · Modul Studi kasus · ±20 menit

Kerangka 5 langkah menjawab soal desain

Urutan yang sama untuk setiap soal: requirement, estimasi, API + data model, desain v1, lalu deep dive yang dibenarkan angka

Sebelumnya, Review 3 menutup semua modul konsep. Mulai lesson ini, konsep dipakai untuk menjawab soal interview klasik. Soal system design berbentuk terbuka ("rancang URL shortener"), jadi tanpa urutan tetap Anda mudah melompat ke komponen favorit dan kehabisan waktu sebelum menyebut angka. Lesson ini memberi satu kerangka yang dipakai di semua studi kasus berikutnya (0028–0034) dan di mock interview 0036.

Target lesson ini: Anda bisa menjawab "Rancang sistem X. Bagaimana Anda memakai 45 menit ini?" tanpa catatan, dalam 60 detik: lima langkah berurutan, pertanyaan klarifikasi standar, alokasi waktu per langkah, kenapa langkah 4 selalu dimulai dari desain v1 paling sederhana, dan kenapa setiap komponen di langkah 5 harus dibenarkan dengan angka.

1. Lima langkah dan alokasi 45 menit

1 · Requirement→ 2 · Estimasi→ 3 · API + data model→ 4 · High-level (v1)→ 5 · Deep dive

Langkah	Hasil yang ditulis di papan	Waktu
1. Klarifikasi requirement	3–5 functional requirement ("user bisa …") dan non-functional requirement dalam angka: jumlah user, 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) dan tabel/entitas utama dengan key-nya	±7 menit
4. High-level design	Desain v1 paling sederhana yang memenuhi angka langkah 2; telusuri satu request tulis dan satu request baca di diagram	±13 menit
5. Deep dive, bottleneck, trade-off	Bottleneck pertama yang muncul dari angka, komponen yang menyelesaikannya, biaya dan risikonya, lalu evolusi v2	±15 menit

Alokasi 5 + 5 + 7 + 13 + 15 = 45 menit adalah konvensi track ini (dipakai juga di timer mock 0036), bukan aturan resmi. Kalau interviewer mengarahkan ke bagian tertentu lebih awal, ikuti arahannya; kerangka adalah peta, bukan naskah.

Kenapa angka dulu: non-functional requirement baru berguna kalau terukur. Google SRE Book mendefinisikan SLI sebagai "a carefully defined quantitative measure of some aspect of the level of service", dan menyebut layanan yang melayani user umumnya peduli pada availability, latency, dan throughput. ^[1] Itu tiga angka pertama yang Anda tanyakan di langkah 1.

2. Pertanyaan klarifikasi standar (langkah 1)

Hafalkan daftar pendek ini. Tanyakan, tulis jawabannya, dan kalau interviewer berkata "terserah Anda", ajukan asumsi dengan angka lalu minta persetujuan.

Functional: fitur inti apa saja (pilih 3–5, sisanya ditandai "di luar scope")? Siapa user-nya: manusia lewat aplikasi, atau service lain lewat API?
Skala: berapa user aktif harian (DAU)? Berapa aksi per user per hari? Rasio baca:tulis?
Latency: target p99 untuk operasi terpenting (mis. redirect < 100 ms)?
Availability: berapa "sembilan"? 99,9% berarti jatah downtime ±43,2 menit per bulan; 99,99% hanya ±4,32 menit. ^[2]
Consistency: boleh telat terlihat beberapa detik (eventual), atau harus langsung terlihat (strong)?
Data: berapa lama data disimpan? Ukuran satu item? Ada data sensitif?

Langkah 2 langsung memakai jawaban ini: QPS = aksi per hari ÷ 10⁵ detik (1 hari ≈ 86.400 detik, dibulatkan), puncak ≈ 2–3× rata-rata, storage = item per hari × ukuran × 365 × tahun. Angka kasar cukup; yang dinilai adalah Anda memakainya untuk memilih desain.

Latihan 1 — Klarifikasi dan waktu

Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0035.

Kuis di lesson ini adalah feedback cepat, bukan bukti penguasaan; yang dicatat hanya hasil review 0035.

3. Langkah 4 selalu mulai dari v1; langkah 5 hanya menambah yang dibenarkan angka

Desain v1 adalah desain paling sederhana yang memenuhi angka langkah 2: sering cukup satu app server (atau dua di belakang load balancer demi availability) dan satu database. Gambar v1, telusuri satu request tulis dan satu request baca, lalu baru tanya: angka mana yang tidak terpenuhi? Google SRE Book menyebut tujuan yang sama dari sisi operasional: tim harus "push back when accidental complexity is introduced", yaitu kompleksitas yang tidak dituntut oleh masalahnya. ^[3]

Di langkah 5, setiap komponen tambahan memakai pola kalimat yang sama:

"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 di kolom kode cukup. Kalau p99 query baca melewati 50 ms pada jam puncak, saya tambah cache; biayanya stale data dan satu komponen lagi yang harus dipantau." Komponen yang muncul tanpa angka (Kafka "untuk jaga-jaga", microservices untuk 1.000 user) adalah tanda over-engineering yang dinilai negatif.

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 yang Anda suka, bukan bottleneck	Pilih bottleneck terbesar menurut angka, atau tanya interviewer mana yang ingin dibahas
Menyebut satu pilihan tanpa trade-off	Selalu sebut biaya: latency, konsistensi, biaya operasional, risiko

Latihan 2 — Susun urutan kerangka

Urutkan lima langkahnya. Gunakan ↑/↓, lalu Periksa.

Klarifikasi requirement: functional dan non-functional dalam angka
Estimasi: QPS rata-rata dan puncak, rasio baca:tulis, storage
API + data model: endpoint inti dan tabel utama dengan key
High-level design: desain v1 paling sederhana yang memenuhi angka
Deep dive: bottleneck, komponen yang dibenarkan angka, trade-off

Requirement menentukan angka, angka menentukan seberapa besar desain, API dan data model membuat diagram konkret, v1 menjadi titik awal, dan deep dive hanya menambah komponen yang dibenarkan bottleneck. Waktu: ±5, 5, 7, 13, 15 menit.

Latihan lisan — Ucapkan dengan suara keras

Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai.

"Interviewer berkata: 'Rancang sebuah sistem; Anda punya 45 menit.' Jelaskan bagaimana Anda akan memakai waktunya." (60 detik)

Bandingkan dengan jawaban contoh dan checklist-nya

"Saya pakai lima langkah. Lima menit pertama untuk klarifikasi: fitur inti, lalu non-functional dalam angka, yaitu DAU, rasio baca:tulis, target p99, availability, dan consistency. Lima menit berikutnya estimasi: QPS rata-rata dan puncak, storage beberapa tahun. Sekitar tujuh menit untuk API dan data model. Lalu tiga belas menit high-level design, dan saya mulai dari v1 paling sederhana yang memenuhi angka tadi, biasanya app server dan satu database, dan saya telusuri satu request baca dan tulis. Lima belas menit terakhir deep dive: saya cari bottleneck dari angka, menambah komponen hanya kalau angkanya menuntut, dan menyebut trade-off-nya, misalnya cache menambah risiko stale data."

Checklist: apakah Anda menyebut…

lima langkah dalam urutan yang benar?
non-functional requirement ditanyakan dalam angka (DAU, p99, availability)?
estimasi QPS puncak dan storage sebelum menggambar?
langkah 4 dimulai dari desain v1 paling sederhana?
alokasi waktu kira-kira 5, 5, 7, 13, 15 menit?
membenarkan komponen dengan angka di langkah 5, beserta trade-off-nya?

Lulus jika minimal 4 dari 6.

Bacaan lanjutan (opsional, tidak dihitung dalam durasi) Google SRE Book, bab 4: Service Level Objectives, ±25 menit. Cara memilih beberapa angka yang benar-benar penting untuk user.

Berikutnya, lesson 0028: kerangka ini dijalankan penuh untuk URL shortener.

Istilah: GLOSSARY.md (bagian "Prinsip dan kerangka" dan "Studi kasus") · Indeks: semua lesson System Design

Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "apa yang saya katakan kalau interviewer menolak memberi angka DAU?", "bagaimana kalau waktu tinggal 10 menit dan saya baru di langkah 3?"

Sumber: [1] Google SRE Book, bab 4: Service Level Objectives · [2] Google SRE Book, Appendix A: Availability Table · [3] Google SRE Book, bab 9: Simplicity