Lesson 0003 · System Design · Modul Fondasi · ±20 menit

Latency vs throughput; angka latency yang perlu dihafal

Dua ukuran yang sering tertukar, kenapa p99 lebih jujur daripada rata-rata, dan enam angka yang menentukan di mana bottleneck berada

Target lesson ini: Anda bisa membedakan latency dan throughput, menjelaskan kenapa SLO latency ditulis sebagai p99 dan bukan rata-rata, dan menyebut urutan orde besaran: memori (±100 ns) ≪ round trip di datacenter (±0,5 ms) ≪ disk seek (±10 ms) ≪ antarbenua (±150 ms).

Sebelumnya, di lesson 0002: request pertama butuh ±3 round trip, dan round trip antarbenua ±150 ms. Lesson ini memberi nama dan ukuran untuk "cepat".

1. Latency vs throughput

Latency adalah "how long it takes to return a response to a request". Throughput adalah berapa banyak request yang bisa dilayani, biasanya dalam request per detik. Google SRE Book menyebut keduanya sebagai SLI yang umum. ^[1]

	Latency	Throughput
Analogi jalan tol	Waktu tempuh satu mobil	Jumlah mobil yang lewat per jam
Satuan	ms per request	request per detik (QPS/RPS)
Menambah server	Biasanya tidak mempercepat satu request	Bisa menaikkan kapasitas total

Menambah lajur tol tidak membuat satu mobil lebih cepat sampai. Begitu juga menambah server: kapasitasnya naik, tapi request yang lambat karena query buruk atau jarak antarbenua tetap lambat. Jadi saat sistem "lambat", tanyakan dulu: latency satu request yang tinggi, atau throughput yang tidak cukup? Obatnya berbeda.

2. Kenapa p99, bukan rata-rata

Percentile ke-n (pn) adalah nilai yang tidak dilampaui oleh n% request. p50 adalah median; p99 berarti 99% request lebih cepat dari angka itu. SRE Book: "Most metrics are better thought of as distributions rather than averages", karena "a simple average can obscure these tail latencies". Contohnya di buku itu: request tipikal selesai sekitar 50 ms, tapi 5% request 20 kali lebih lambat. Percentile tinggi seperti p99 atau p99,9 "shows you a plausible worst-case value". ^[1]

Ekor lambat makin penting kalau satu halaman memanggil banyak service. Hitungan sederhana: kalau satu panggilan punya peluang 1% lambat (melewati p99), halaman yang memanggil 100 service sekaligus punya peluang 1 − 0,99¹⁰⁰ ≈ 63% terkena minimal satu panggilan lambat. Yang tadinya "1% user" menjadi mayoritas user.

3. Angka yang perlu dihafal

Jeff Dean menyebut tabel ini "Numbers Everyone Should Know" (2009). ^[2] Yang perlu Anda ingat bukan angka persisnya, tapi jaraknya: setiap baris kira-kira berbeda satu atau dua orde besaran.

Skala logaritmik: setiap 60 px = 10 kali lebih lambat. Angka dari Jeff Dean (2009); disk di sini adalah hard disk berputar.

Operasi	Waktu	Kesimpulan untuk desain
Main memory reference	100 ns	Membaca dari memori jauh lebih murah daripada apa pun lewat jaringan: dasar cache (lesson 0013).
Round trip di dalam datacenter	500.000 ns = 0,5 ms	Satu panggilan ke service atau database lain ±0,5 ms. Sepuluh panggilan berurutan = 5 ms.
Disk seek	10 ms	Akses acak ke hard disk mahal; baca berurutan jauh lebih efisien. Index (lesson 0009) menghindari baca acak yang tidak perlu.
Paket California → Belanda → California	150 ms	Jarak fisik tidak bisa dikalahkan kode. Dekatkan data ke user (CDN, lesson 0007).

Tabel ini dari 2009. Perangkat keras sudah berubah (SSD jauh lebih cepat daripada hard disk berputar), jadi jangan mengutip angka disk itu sebagai angka hari ini. Yang tetap berlaku untuk interview adalah urutannya: memori ≪ jaringan di datacenter ≪ disk acak ≪ antarbenua.

Latihan 1 — Latency, throughput, percentile

Latihan 2 — Orde besaran

Latihan lisan — Jawab lisan

Pasang timer, jawab dengan suara keras, baru buka jawaban contoh. Soal ini juga ada di bank soal dan bisa ditarik review 0012.

"Rata-rata latency API kami 80 ms, tapi user tetap mengeluh lambat. Apa yang Anda periksa, dan bagaimana Anda menulis target latency-nya?" (60 detik)

Bandingkan dengan jawaban contoh dan checklist-nya

"Rata-rata menyembunyikan ekor. Latency itu distribusi, jadi saya lihat percentile: p50, p95, p99. Bisa saja p50-nya 50 ms tapi 5% request 20 kali lebih lambat; rata-rata tetap terlihat wajar. Kalau satu halaman memanggil banyak service, ekor itu kena hampir semua user: dengan 100 panggilan, peluang minimal satu melewati p99 sekitar 63%. Jadi target saya tulis sebagai percentile, misalnya p99 di bawah 300 ms. Lalu saya cari sumber ekornya dengan orde besaran: panggilan jaringan di datacenter ±0,5 ms, akses disk acak jauh lebih mahal, antarbenua ±150 ms. Saya juga pisahkan apakah masalahnya latency per request atau throughput yang kurang, karena menambah server tidak mempercepat request yang lambat karena query buruk."

Checklist: apakah Anda menyebut…

rata-rata menyembunyikan tail latency; latency adalah distribusi?
lihat percentile (p50, p95, p99) dan arti p99?
target ditulis sebagai percentile, mis. "p99 < 300 ms"?
fan-out ke banyak service memperbesar dampak ekor (mis. 100 panggilan → ±63%)?
orde besaran untuk mencari sumber lambat (memori, jaringan datacenter, disk, antarbenua)?
membedakan masalah latency dan throughput (menambah server tidak mempercepat satu request)?

Lulus kalau minimal 4 dari 6.

Bacaan utama Google SRE Book, bab 4 "Service Level Objectives", bagian "Indicators" dan "Aggregation". ±15 menit. Opsional, tidak dihitung dalam durasi.

Berikutnya, lesson 0004: dengan angka-angka ini, bagaimana menghitung kasar berapa request per detik, storage, dan bandwidth yang dibutuhkan, dan membuktikan bahwa 1.000 user cukup dilayani satu server?

Ada yang belum jelas? Tanyakan ke agent. Agent adalah guru Anda di track ini.

Istilah: GLOSSARY.md (bagian "Fondasi") · Sumber: RESOURCES.md

Sumber: [1] Google SRE Book, bab 4 Service Level Objectives · [2] Jeff Dean, LADIS 2009 ("Numbers Everyone Should Know")