Estimasi back-of-envelope: QPS, storage, bandwidth
Tiga rumus, dua angka bantu, dan satu kebiasaan: biarkan hitungan, bukan selera, yang memilih komponen
Sebelumnya, di lesson 0003: throughput diukur dalam request per detik, dan satu round trip di datacenter ±0,5 ms. Lesson ini memakai angka itu untuk menjawab pertanyaan langkah 2 di setiap soal desain: seberapa besar bebannya?
1. Kenapa menghitung, dan seberapa teliti
Back-of-envelope berarti hitungan kasar yang cukup ditulis di balik amplop: orde besaran, bukan angka tepat. Jeff Dean (Google) menyebut "ability to estimate performance of a system design – without actually having to build it" sebagai keterampilan penting. [1] Contohnya di slide yang sama: membaca 30 thumbnail satu per satu dari disk butuh 30 × 10 ms seek + waktu baca ≈ 560 ms, sedangkan membacanya paralel ≈ 18 ms. Dua desain dibandingkan sebelum satu baris kode pun ditulis. [1]
Di interview, estimasi punya satu fungsi: menentukan apakah komponen tambahan dibutuhkan. Bulatkan dengan bebas, sebutkan asumsi Anda dengan suara keras, dan jangan habiskan lebih dari ±5 menit. Kalau hasilnya 0,2 QPS, ketelitian ±50% pun tidak mengubah keputusan.
2. Dua angka bantu
1 hari ≈ 10⁵ detik. Persisnya 24 × 3.600 = 86.400 detik. Dibulatkan ke 10⁵ supaya pembagian bisa dilakukan di kepala: 10 juta request per hari = 10⁷ / 10⁵ = 100 QPS.
Pangkat 2 ≈ pangkat 10. 2¹⁰ = 1.024 ≈ 10³. Setiap tambahan 10 pada pangkat dua menambah tiga nol:
| Pangkat 2 | ≈ Pangkat 10 | Satuan | Dipakai untuk |
|---|---|---|---|
| 2¹⁰ | 10³ (seribu) | KB | Satu baris data kecil (profil user, satu pesan dengan metadata): ±1 KB |
| 2²⁰ | 10⁶ (juta) | MB | Satu foto hasil kompres: ratusan KB sampai beberapa MB |
| 2³⁰ | 10⁹ (miliar) | GB | Memori satu server: puluhan sampai ratusan GB |
| 2⁴⁰ | 10¹² (triliun) | TB | Data bertahun-tahun milik layanan besar |
Ukuran di kolom terakhir adalah asumsi yang Anda sebutkan ke interviewer, bukan fakta yang dihafal. Satu lagi: jaringan diukur dalam bit per detik (Mbps, Gbps), storage dalam byte. 1 byte = 8 bit, jadi 100 MB/s = 800 Mbps.
3. Tiga rumus
- QPS (queries per second, request per detik) = DAU × request per user per hari / 10⁵. DAU (daily active users) adalah jumlah user yang memakai sistem minimal sekali sehari, bukan jumlah akun terdaftar.
- QPS puncak = QPS rata-rata × faktor puncak. Faktor ini asumsi: aplikasi kantor sibuk di jam 8–9 pagi, aplikasi hiburan di malam hari. Cara menghitungnya: kalau 30% request harian datang dalam satu jam, puncaknya 0,3 × total / 3.600.
- Storage = jumlah record baru per hari × ukuran per record × 365 × jumlah tahun disimpan. Tambahkan index dan replika kalau relevan.
- Bandwidth = QPS × ukuran per request atau response. Hitung baca dan tulis terpisah; biasanya baca jauh lebih banyak.
4. Contoh: 1.000 DAU, dan kenapa satu server + satu database cukup
Soal: aplikasi internal kantor, 1.000 karyawan, masing-masing ±20 request per hari.
| Langkah | Hitungan | Hasil |
|---|---|---|
| Request per hari | 1.000 × 20 | 20.000 |
| QPS rata-rata | 20.000 / 10⁵ | 0,2 QPS |
| QPS puncak (30% dalam satu jam) | 6.000 / 3.600 | ±2 QPS |
| Storage per tahun (1.000 record/hari × 1 KB) | 1 MB × 365 | ±365 MB |
Berapa yang sanggup dilayani satu server? Pakai angka lesson 0003: satu round trip ke database di datacenter ±0,5 ms. [1] Anggap satu request memanggil database beberapa kali dan menghabiskan total ±10 ms. Kalau server hanya mengerjakan satu request sekaligus pun, itu 1.000 ms / 10 ms = 100 request per detik, 50 kali di atas puncak 2 QPS. Data 365 MB per tahun muat dengan mudah di satu database.
Kesimpulannya: 1.000 DAU ≈ di bawah 1 QPS rata-rata, satu server + satu database sudah cukup. Load balancer, cache, queue, atau microservices di sini tidak dibenarkan angka mana pun. Yang dibutuhkan hanya backup dan monitoring, supaya Anda tahu kapan angka itu berubah.
Ini prinsip inti track ini dalam bentuk angka: ukur (atau hitung) dulu, lalu pilih desain termurah yang memenuhi angka. Ucapkan di interview: "Untuk skala ini cukup satu server; kalau puncak naik ke ratusan QPS atau p99 melewati target, saya ukur dulu, lalu mulai dari index atau cache."
Latihan 1 — QPS dan desain v1
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0012.
Latihan 2 — Storage, bandwidth, pangkat 2
Latihan hitung — Kerjakan di kertas dulu
Tulis asumsi dan hitungan Anda, baru buka kuncinya. Jawaban dalam orde besaran yang sama sudah benar.
Soal A. Aplikasi chat: 10 juta DAU, masing-masing mengirim 40 pesan per hari. Berapa QPS tulis rata-rata dan puncaknya (asumsikan puncak 2 kali rata-rata)?
Lihat jawaban
10⁷ × 40 = 4 × 10⁸ pesan per hari. 4 × 10⁸ / 10⁵ = 4.000 QPS rata-rata, puncak ±8.000 QPS. Angka ini sudah jauh di atas 100 request per detik dari contoh satu server di bagian 4, jadi di sinilah pertanyaan tentang beberapa server dan pembagian beban mulai masuk akal (modul Skalabilitas).
Soal B. Masih aplikasi chat yang sama: setiap pesan rata-rata 100 byte termasuk metadata. Berapa storage per hari dan per tahun?
Lihat jawaban
4 × 10⁸ pesan × 100 byte = 4 × 10¹⁰ byte = 40 GB per hari. Dikali 365 ≈ 14.600 GB ≈ 15 TB per tahun, belum termasuk index dan replika. 15 TB per tahun adalah sinyal untuk memikirkan masa simpan data dan cara membagi data, bukan sesuatu yang dipasang di desain v1 aplikasi kecil.
Soal C. Aplikasi foto: 1 juta DAU, masing-masing melihat 50 foto per hari, setiap foto 200 KB. Berapa QPS baca dan bandwidth keluarnya, dalam MB/s dan Mbps?
Lihat jawaban
10⁶ × 50 = 5 × 10⁷ tampilan per hari / 10⁵ = 500 QPS baca. 500 × 200 KB = 10⁵ KB/s = 100 MB/s, dikali 8 = 800 Mbps. Bandwidth sebesar itu untuk file statis adalah sinyal untuk menaruh foto lebih dekat ke user (CDN, lesson 0007); QPS-nya sendiri belum menuntut banyak server.
Soal D. Sistem absensi 5.000 karyawan, masing-masing check-in dan check-out sekali sehari, semuanya check-in antara 07.30 dan 08.30. Berapa QPS puncaknya, dan apa desain v1-nya?
Lihat jawaban
5.000 check-in dalam satu jam = 5.000 / 3.600 ≈ 1,4 QPS puncak. Rata-rata hariannya 10.000 / 10⁵ = 0,1 QPS. Desain v1: satu app server + satu database. Puncak harian 14 kali rata-rata pun masih jauh di bawah kapasitas satu server.
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 0012.
"Rancang aplikasi pemesanan ruang rapat untuk kantor dengan 1.000 karyawan. Lakukan estimasi kasar, lalu sebutkan desain v1 Anda." (90 detik)
Bandingkan dengan jawaban contoh dan checklist-nya
"Asumsi saya: 1.000 karyawan semuanya aktif, masing-masing sekitar 10 request per hari untuk melihat jadwal, memesan, dan membatalkan. 10.000 dibagi 10⁵ detik per hari ≈ 0,1 QPS rata-rata. Puncaknya pagi hari: kalau 30% request datang dalam satu jam, itu 3.000 / 3.600 ≈ 1 QPS. Storage: sekitar 1.000 pemesanan per hari × 1 KB ≈ 1 MB per hari, ±365 MB per tahun. Satu server yang melayani satu request sekaligus pun mampu sekitar 100 request per detik. Jadi desain v1: satu app server dan satu database, plus backup. Kalau nanti dipakai seluruh grup perusahaan dan puncak naik ke ratusan QPS, atau p99 melewati target, saya ukur dulu dan mulai dari perubahan termurah seperti index atau cache."
Checklist: apakah Anda menyebut…
- asumsi eksplisit: jumlah DAU dan request per user per hari?
- QPS rata-rata = total request per hari / 10⁵ detik?
- QPS puncak dari asumsi jam sibuk, bukan hanya rata-rata?
- storage = jumlah record × ukuran × masa simpan?
- kesimpulan satu app server + satu database, dibenarkan dengan angka?
- sinyal kapan desain berubah (QPS puncak atau p99) dan langkah termurah berikutnya?
Lulus kalau minimal 4 dari 6.
Berikutnya, lesson 0005: kalau hitungan seperti Soal A menunjukkan satu server tidak cukup, pilihannya server yang lebih besar atau lebih banyak server. Kapan masing-masing, dan apa syaratnya?
Istilah: GLOSSARY.md (bagian "Fondasi") · Indeks: semua lesson System Design
Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "Beri saya satu soal estimasi lagi untuk aplikasi e-commerce", "Kenapa faktor puncak tidak selalu 2 kali?"