Lesson 0025 · System Design · Modul Reliabilitas & API · ±20 menit

Tangga skala: ukur dulu, arsitektur baru jalan terakhir

Delapan anak tangga dari mengukur sampai memecah service, biaya dan risiko masing-masing, sinyal kapan naik, dan satu kalimat yang membuat Anda terdengar senior tanpa over-engineering

Sebelumnya, di lesson 0024, memecah service disebut sebagai jalan terakhir. Setiap lesson komponen, mulai lesson 0005, punya bagian "Kapan tidak perlu", sesuai janji di lesson 0001. Lesson ini merangkai semuanya menjadi satu urutan yang bisa Anda ucapkan di interview mana pun.

Target lesson ini: Anda bisa menyusun delapan anak tangga skala dari ingatan (ukur → query/index → cache → scale vertical → read replica → queue → sharding → pecah service), menyebut biaya, risiko, dan sinyal untuk naik ke setiap anak tangga, lalu mengucapkan keputusan dengan pola "untuk skala ini cukup X; kalau metrik Y melewati Z, langkah berikutnya W".

1. Prinsipnya: ukur, lalu perubahan termurah

Setiap komponen baru memecahkan satu masalah dan menambah biaya: server yang harus dijalankan, kegagalan baru yang harus ditangani, dan hal baru yang harus dipahami tim. SRE Book menyebut "boring" sebagai sifat positif untuk software, dan membedakan kompleksitas esensial (melekat pada masalah) dari kompleksitas aksidental (yang kita tambahkan sendiri dan bisa dihilangkan). ^[1] Tangga skala adalah cara menjaga kompleksitas aksidental tetap kecil: naik satu anak tangga hanya kalau angka menuntut.

Anak tangga 1–3 hampir tidak mengubah arsitektur. Anak tangga 4–5 menambah mesin. Anak tangga 6–8 mengubah cara sistem bekerja dan paling mahal dibatalkan.

2. Delapan anak tangga

Angka sinyal di tabel adalah contoh titik awal yang masuk akal untuk interview, bukan aturan baku. Yang penting, setiap kenaikan punya angka yang disebut.

Anak tangga	Biaya	Risiko	Sinyal untuk naik ke sini
1. Ukur: metrik, profiling, query plan	Hampir nol	Tidak ada	Selalu pertama. Empat golden signals (latency, traffic, errors, saturation) ^[2] dan `EXPLAIN` untuk melihat query plan ^[3]
2. Perbaiki kode, query, index	Jam kerja engineer	Kecil; index menambah overhead saat menulis ^[4]	`EXPLAIN` menunjukkan scan seluruh tabel baris demi baris ^[4], query N+1, atau satu query mendominasi waktu
3. Cache (0013)	Satu komponen (Redis) atau cache di proses	Data basi; invalidation ^[5]	Beban didominasi baca berulang ke key yang sama, data jarang berubah
4. Scale vertical (0005)	Mesin lebih mahal, tanpa ubah kode	Ada batas atas; tetap satu titik gagal	CPU atau memori di atas ±70% terus-menerus setelah query diperbaiki
5. Read replica (0009)	Satu database lagi, routing baca	Replication lag: user tidak langsung melihat tulisannya sendiri	Sebagian besar query adalah baca dan primary tetap jenuh; standby bisa melayani query read-only ^[6]
6. Asinkron / queue (0016)	Broker + worker	Eventual, pesan ganda, butuh idempotency	Pekerjaan lambat di jalur request (email, gambar) atau beban yang naik-turun tajam; queue menjadi buffer yang meratakan puncak ^[7]
7. Sharding (0010)	Banyak primary, logika routing	Query lintas shard, resharding, hot partition	Beban tulis atau ukuran data melewati satu primary terbesar yang masuk akal
8. Pecah service (0024)	Deploy, monitoring, tracing per service	Panggilan jaringan, distributed transaction, kompleksitas sistem ^[8]	Masalah tim (banyak tim saling menunggu deploy) atau kebutuhan skala yang sangat berbeda per bagian

Latihan 1 — Susun tangga skala

Susun dari yang pertama dicoba sampai yang terakhir. Ucapkan sinyal untuk naik ke setiap anak tangga dengan suara keras saat memindahkannya.

Ukur: golden signals, profiling, EXPLAIN query yang lambat
Perbaiki kode/query, tambah index yang hilang
Pasang cache untuk baca berulang (cache-aside + TTL)
Scale vertical: mesin yang lebih besar, tanpa ubah kode
Tambah read replica untuk beban baca
Pindahkan pekerjaan lambat ke queue (asinkron)
Sharding saat beban tulis atau data melewati satu primary
Pecah service saat masalahnya tim atau kebutuhan skala yang berbeda

Urutannya mengikuti biaya dan risiko. Mengukur tidak mengubah apa pun. Index dan cache tidak mengubah arsitektur. Mesin besar dan replica menambah mesin, tapi kode hampir sama. Queue, sharding, dan pecah service mengubah cara sistem bekerja (eventual consistency, routing data, panggilan jaringan) dan paling mahal dibatalkan.

Latihan 2 — Anak tangga mana?

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

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

3. Anti-pattern: over-engineering

Contoh klasik: kandidat menerima soal "aplikasi pemesanan untuk 1.000 user", lalu menggambar API gateway, sepuluh microservices, Kafka, Redis cluster, dan database yang di-shard. Hitung dulu (lesson 0004):

1.000 user aktif harian→ × ±10 request/hari = 10⁴→ ÷ 10⁵ detik/hari ≈ 0,1 QPS→ puncak ×10 ≈ 1 QPS: satu server + satu database

Satu QPS bisa dilayani hampir semua server. Setiap komponen di gambar tadi adalah kompleksitas aksidental: tidak ada angka yang membenarkannya. Interviewer membaca ini sebagai tanda kandidat menghafal arsitektur besar tanpa memahami kapan arsitektur itu dibutuhkan. "Supaya siap kalau viral" bukan pembenaran; jawaban yang kuat menyebut apa yang akan diukur dan pada angka berapa desain berubah.

Tanda Anda mulai over-engineer:

Komponen muncul sebelum langkah estimasi selesai.
Anda tidak bisa menyebut angka yang membuat komponen itu perlu.
Desain v1 sudah berisi anak tangga 6–8.
Alasannya "best practice" atau "perusahaan besar memakainya", bukan bottleneck yang disebut.

4. Cara mengucapkannya di interview

Satu pola kalimat menunjukkan bahwa Anda tahu solusi besarnya dan tahu kapan memakainya:

"Untuk skala ini cukup X; kalau metrik Y melewati Z, langkah berikutnya W."

"Untuk skala ini cukup satu PostgreSQL dengan index di customer_id; kalau CPU database di atas 70% terus-menerus dan sebagian besar query adalah baca, langkah berikutnya read replica."
"Untuk skala ini cukup kirim email langsung dari request; kalau p99 checkout naik karena email, atau volumenya melewati ratusan per menit, langkah berikutnya queue dan worker."
"Untuk skala ini cukup monolith; kalau tiga tim mulai saling menunggu deploy, langkah berikutnya memisahkan modul yang paling sering berubah."

Di kerangka 5 langkah (lesson 0027), pola ini dipakai di langkah 4 (desain v1 paling sederhana) dan langkah 5 (setiap komponen yang ditambahkan disertai angkanya).

Latihan 3 — Over-engineering

Latihan lisan — Ucapkan dengan suara keras

Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai. Soal ini juga ada di bank soal dan bisa ditarik review 0026.

"Aplikasi kita yang sekarang satu server dan satu database mulai lambat setelah traffic naik sepuluh kali lipat. Jelaskan urutan langkah Anda, dari yang pertama." (90 detik)

Bandingkan dengan jawaban contoh dan checklist-nya

"Pertama saya ukur: empat golden signals untuk melihat apakah yang jenuh CPU aplikasi, database, atau koneksi, lalu EXPLAIN untuk query paling lambat. Biasanya perbaikan termurah ada di sana: index yang hilang, query N+1, atau query yang mengambil terlalu banyak kolom. Kalau masalahnya baca berulang ke data yang sama, saya pasang cache-aside dengan TTL dan menerima risiko data agak basi. Kalau database masih jenuh, scale vertical dulu karena tanpa ubah kode, lalu read replica untuk beban baca, dengan risiko replication lag. Pekerjaan lambat seperti kirim email saya pindah ke queue supaya tidak di jalur request. Sharding baru kalau beban tulis atau ukuran data melewati satu primary yang sudah besar, dan pecah service hanya kalau masalahnya tim atau kebutuhan skala yang berbeda. Jadi jawabannya: untuk skala ini cukup index dan cache; kalau CPU database tetap di atas 70% setelah itu, langkah berikutnya replica."

Checklist: apakah Anda menyebut…

mulai dari mengukur (golden signals, EXPLAIN), bukan menebak?
perbaiki query/index sebelum menambah komponen?
cache, lalu scale vertical, lalu read replica, dengan risikonya (stale data, replication lag)?
queue untuk pekerjaan lambat atau beban yang naik-turun?
sharding dan pecah service sebagai anak tangga terakhir dengan sinyalnya?
kalimat "untuk skala ini cukup X; kalau metrik Y melewati Z, langkah berikutnya W"?

Lulus jika minimal 4 dari 6.

Bacaan lanjutan (opsional, tidak dihitung dalam durasi) Google SRE Book, ch. 9: Simplicity, ±10 menit.

Berikutnya, review 0026: uji modul Asinkron dan Reliabilitas & API tanpa catatan. Setelah itu, modul Studi kasus memakai tangga ini di setiap soal.

Istilah: GLOSSARY.md (bagian "Prinsip dan kerangka" dan "Reliabilitas & API") · Indeks: semua lesson System Design

Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "Kapan queue sebaiknya naik sebelum read replica?", "Beri saya soal skenario dan nilai urutan tangga yang saya ucapkan."

Sumber: [1] Google SRE Book, ch. 9: Simplicity · [2] Google SRE Book, ch. 6: Monitoring Distributed Systems · [3] PostgreSQL docs: Using EXPLAIN · [4] PostgreSQL docs: Indexes, Introduction · [5] Azure Architecture Center: Cache-Aside pattern · [6] PostgreSQL docs: Hot Standby · [7] Azure Architecture Center: Queue-Based Load Leveling pattern · [8] Azure Architecture Center: Microservices architecture style