Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.
Dari daily active users ke QPS, storage, bandwidth, ukuran cache dan jumlah server, lengkap dengan contoh photo-sharing dan estimator TypeScript.
Matthews Wong
Software Engineer
Ringkasan Utama
Back-of-the-envelope capacity estimation mengubah beberapa asumsi yang dinyatakan jelas menjadi order of magnitude. Daily active users memberi request per hari, dibagi 86.400 detik jadi QPS rata-rata, peak multiplier memberi peak QPS, dan ukuran record x retention x replika memberi storage. Bandwidth, ukuran cache dan jumlah server mengikuti pola yang sama, tiap asumsi ditandai untuk diukur nanti.
Seseorang bilang layanan akan punya dua juta pengguna harian dan bertanya apakah satu server cukup. Jawaban yang jujur berupa angka, dan angka itu bisa didapat dalam dua menit kalau Anda tahu rantainya: pengguna, request, query per detik, byte, cache, mesin. Tanpa rantai itu, diskusi berubah jadi adu pendapat soal perlu sharding atau tidak.
Post ini adalah metode generik beserta checklist yang bisa dipakai ulang. Tiap langkah diturunkan dengan aritmetika yang ditampilkan, estimator TypeScript dijalankan pada contoh photo-sharing dengan output aslinya, dan ada tabel powers of two serta angka latency yang layak dihafal. Post URL shortener, chat, news feed, web crawler dan video streaming di seri ini masing-masing menerapkan metode ini pada input mereka sendiri. Setiap angka di bawah diturunkan dari asumsi yang dinyatakan atau dikutip dari sumber di akhir; tidak ada yang merupakan benchmark hasil ukur saya.
Ini cara mendapat jawaban yang akurat dalam faktor dua atau sepuluh dari asumsi yang bisa Anda tulis satu baris masing-masing. Tugasnya memilih kelas arsitektur: apakah satu box Postgres dan satu instance Redis sudah cukup, atau perlu sharding, CDN dan satu fleet di belakang load balancer. Ini bukan forecasting dan bukan benchmark. Benchmark mengukur sistem yang berjalan; estimasi menentukan apakah sistem itu layak dibangun dengan cara tersebut.
Kasus termurah adalah estimasi yang menyuruh Anda berhenti. Ambil ERP carwash yang menerbitkan 200 struk per hari, dengan asumsi sekitar 2 KB per struk sebagai ilustrasi. 200 struk / 86.400 detik adalah 0,0023 write per detik, dan 200 x 2 KB x 365 hari adalah 146.000 KB, atau 146 MB per tahun. Bahkan pada volume 100 kali lipat, satu VPS masih memuatnya dengan lega. Output estimasi yang paling berguna sering berupa kalimat bahwa ini tidak butuh desain terdistribusi, dan biayanya satu menit.
Setiap input adalah tebakan, dan tebakan saling dikalikan. Tiga input yang masing-masing meleset 2x bisa membuat hasil meleset 8x. Perlakukan output sebagai order of magnitude, dan tulis asumsinya di sebelahnya agar siapa pun bisa menantang asumsi yang salah.
Kalikan daily active users (DAU) dengan aksi per pengguna per hari untuk mendapat request per hari, lalu bagi dengan jumlah detik dalam sehari. Sehari adalah 86.400 detik, yang dibulatkan jadi 10^5 untuk hitungan di kepala dengan error 16 persen, masih bisa diterima pada presisi ini. Layanan contoh punya 2.000.000 DAU, masing-masing melihat 30 foto dan rata-rata mengunggah 0,2 foto per hari. Itu 2.000.000 x 30 = 60.000.000 read per hari dan 2.000.000 x 0,2 = 400.000 write per hari. Dibagi 86.400, rata-ratanya 694,44 read per detik dan 4,63 write per detik.
Rata-rata tidak menentukan ukuran fleet, karena traffic tidak datar. Kalikan dengan peak multiplier untuk mendapat peak QPS. Saya pakai 3 di sini, dan itu asumsi, bukan konstanta: ganti dengan rasio jam tersibuk terhadap rata-rata harian dari metrik Anda sendiri, dan pakai angka lebih tinggi untuk sale, launch atau tanggal gajian. Dengan 3, peak read adalah 694,44 x 3 = 2.083,33 per detik dan peak write 4,63 x 3 = 13,89 per detik.
Rasio read:write adalah angka yang memberi tahu apa yang harus dioptimalkan. Di sini 60.000.000 / 400.000 = 150 banding 1, yang mengarah ke cache, read replica dan CDN. Rasio mendekati 1 atau lebih kecil mengarah ke jalur write: storage yang ramah append, batching dan queue. Hitung kedua laju secara terpisah, karena DAU yang sama bisa menggambarkan dua sistem yang sangat berbeda.
Storage adalah record per hari x byte per record x 365 x tahun retention x replication factor. Untuk layanan foto, asumsikan 1.000 KB untuk file asli, 150 KB untuk varian hasil resize dan 1 KB metadata, jadi 1.151 KB per upload. 400.000 upload x 1.151 KB = 460,4 GB per hari. Dalam 5 tahun jadi 460,4 GB x 365 x 5 = 840 TB, dan dengan 3 salinan (pilihan umum, dan di sini sebuah asumsi) jadi 2,52 PB. Metadata hanya 0,09 persen dari total byte, jadi file asli yang menentukan pilihan storage: object storage, bukan baris di database.
Bandwidth adalah peak QPS x byte per request, di tiap arah. Ingress membawa upload beserta variannya: 13,89 upload per detik x 1.150 KB = 15,97 MB/s, yaitu 127,78 Mbps. Egress membawa setiap foto yang dilihat, diasumsikan varian 150 KB: 2.083,33 view per detik x 150 KB = 312,5 MB/s. Link jaringan dinyatakan dalam bit, jadi kalikan byte dengan 8: 312,5 MB/s adalah 2.500 Mbps, atau 2,5 Gbps.
Bandingkan angka itu dengan port yang benar-benar Anda punya. Kalau provider memberi satu server port 1 Gbps (cek paketnya, bervariasi), egress 2,5 Gbps berarti jawabannya CDN atau object storage dengan edge sendiri, bukan application server yang lebih besar. Bandwidth adalah titik di mana desain yang tampak aman hanya dari sisi QPS paling sering jebol.
Titik awal yang umum adalah meng-cache 20 persen terpanas dari data yang dibaca dalam sehari, meminjam aturan 80/20 dari prinsip Pareto: kira-kira 80 persen request jatuh ke 20 persen item. Perlakukan ini sebagai heuristic, bukan hukum. Skew akses nyata berbeda per workload, dan workload dengan distribusi lebih datar butuh cache lebih besar untuk hit ratio yang sama. Untuk layanan foto, metadata 1 KB per read, jadi 0,2 x 60.000.000 read x 1 KB = 12 GB, yang muat di satu instance Redis. Metode yang sama pada varian gambar 150 KB menghasilkan 0,2 x 60.000.000 x 150 KB = 1,8 TB, jauh terlalu besar untuk RAM, jadi gambar ditaruh di edge CDN atau disk cache.
Aritmetika ini mengalikan jumlah read, bukan jumlah objek unik, sehingga melebihkan ukuran cache saat item populer berulang, yang menjadikannya batas atas yang aman. Jika cache lalu mencapai hit ratio 80 persen, hanya 20 persen read yang lolos ke bawah: 2.083,33 x 0,2 = 416,67 read per detik mencapai database saat peak. Itulah angka untuk menentukan ukuran database, dan lima kali lebih rendah dari peak mentah.
Setelah launch, catat hit ratio asli dan jumlah key unik asli selama satu hari. Ganti tebakan 20 persen dengan angka terukur, dan estimasi cache Anda berhenti jadi heuristic.
Bagi peak QPS dengan kemampuan satu instance, sisakan headroom. Angka per instance adalah mata rantai terlemah, karena handler yang menjalankan satu query ber-index dan handler yang me-resize gambar berbeda berordo-ordo besar. Nyatakan sebagai asumsi dan ganti dengan hasil load test begitu Anda bisa menjalankannya. Contoh ini memakai 500 request per detik per instance dan target utilisation 50 persen.
servers = ceil( peakQps / (perInstanceRps * targetUtilisation) )
// peakQps = 2,083.33 + 13.89 = 2,097.22 (from the QPS step)
// perInstanceRps = 500 ASSUMPTION - replace it with a load-test result
// targetUtilisation = 0.5 headroom for spikes, deploys and a dead node
servers = ceil( 2,097.22 / (500 * 0.5) ) = ceil( 8.39 ) = 9
// Cross-check with Little's law: in flight = arrival rate * time in system
// 2,097.22 req/s * 0.05 s (assumed 50 ms per request) = 104.86 concurrent requests
// 104.86 / 9 servers = about 12 in flight per serverHasilnya 9 application server, atau 10 kalau Anda ingin satu cadangan agar satu node boleh mati tanpa membuat kapasitas kurang. Little's law, rata-rata jumlah dalam sistem sama dengan laju kedatangan dikali waktu di dalamnya, memberi sudut pandang kedua: sekitar 105 request in flight, kira-kira 12 per server. Kalau angka itu jauh berbeda dari ukuran connection pool atau jumlah worker Anda, salah satu asumsi keliru, dan ketidakcocokan itu memberi tahu mana yang harus diukur.
Hitungan storage lebih cepat kalau Anda hafal powers of two. Tiap naik satu tingkat dikali 1.024, dan untuk estimasi dibulatkan jadi seribu lalu lanjut. Nama KB, MB dan GB dipakai longgar untuk satuan berbasis 1.000 maupun 1.024; nama IEC KiB, MiB dan GiB adalah yang presisi untuk biner.
| Pangkat | Byte tepat | Nama dan pembulatan |
|---|---|---|
| 2^10 | 1.024 | 1 KiB, sekitar seribu byte |
| 2^20 | 1.048.576 | 1 MiB, sekitar sejuta byte |
| 2^30 | 1.073.741.824 | 1 GiB, sekitar semiliar byte |
| 2^40 | 1.099.511.627.776 | 1 TiB, sekitar satu triliun byte |
| 2^50 | 1.125.899.906.842.624 | 1 PiB, sekitar satu kuadriliun byte |
Untuk waktu, satu hari adalah 86.400 detik, mendekati 10^5. Satu tahun adalah 365 x 86.400 = 31.536.000 detik, dan satu request per detik berarti 86.400 per hari atau 2.592.000 dalam bulan 30 hari. Untuk latency, daftar yang biasa dinisbatkan ke Jeff Dean, aslinya dari Peter Norvig, berlabel sekitar 2012 pada gist yang beredar. Ini baris yang penting untuk estimasi:
Pakai untuk rasio, bukan sebagai pengukuran terkini. Gist itu menanggali angkanya sekitar 2012, dan halaman interaktif Colin Scott menunjukkan bagaimana angka bergeser per tahun; kodenya mengakui angka Norvig tahun 2002 sebagai aslinya. Hardware sudah berubah sejak itu, jadi kutip rasionya: main memory reference 100 ns berbanding random read SSD 150 us adalah 1.500 kali, dan disk seek 10 ms berbanding round trip datacenter 500 us adalah 20 kali. Rasio itulah yang membuat satu cache hit mengubah desain, dan lebih tahan lama daripada satu angka absolut mana pun.
Berikut seluruh rantai sebagai estimator TypeScript untuk contoh photo-sharing. Isinya satu fungsi, satu objek asumsi dan tanpa dependency, sehingga tiap input terlihat dan rumusnya sama dengan aritmetika di atas.
// estimate.ts - run with: node estimate.ts (Node 22.18+ strips the types)
// Decimal units (1 MB = 1,000 KB) on purpose: the gap to 1,024 compounds at
// 2.4 percent per prefix step (about 10 percent by TB), still smaller than
// the error in the inputs.
interface Assumptions {
dau: number;
readsPerUserPerDay: number;
writesPerUserPerDay: number;
peakMultiplier: number;
originalKb: number;
variantsKb: number;
metadataKb: number;
servedKb: number;
retentionYears: number;
replicas: number;
hotFraction: number;
perInstanceRps: number;
targetUtilisation: number;
}
const SECONDS_PER_DAY = 86_400;
function estimate(a: Assumptions) {
const reads = a.dau * a.readsPerUserPerDay;
const writes = a.dau * a.writesPerUserPerDay;
const avgReadQps = reads / SECONDS_PER_DAY;
const avgWriteQps = writes / SECONDS_PER_DAY;
const peakReadQps = avgReadQps * a.peakMultiplier;
const peakWriteQps = avgWriteQps * a.peakMultiplier;
const bytesPerPhotoKb = a.originalKb + a.variantsKb + a.metadataKb;
const newGbPerDay = (writes * bytesPerPhotoKb) / 1_000_000;
const rawTb = (newGbPerDay * 365 * a.retentionYears) / 1_000;
const replicatedTb = rawTb * a.replicas;
const ingressMBps = (peakWriteQps * (a.originalKb + a.variantsKb)) / 1_000;
const egressMBps = (peakReadQps * a.servedKb) / 1_000;
const metadataCacheGb = (a.hotFraction * reads * a.metadataKb) / 1_000_000;
const servers = Math.ceil(
(peakReadQps + peakWriteQps) / (a.perInstanceRps * a.targetUtilisation),
);
return {
reads, writes, avgReadQps, avgWriteQps, peakReadQps, peakWriteQps,
newGbPerDay, rawTb, replicatedTb,
ingressMBps, ingressMbps: ingressMBps * 8,
egressMBps, egressGbps: (egressMBps * 8) / 1_000,
metadataCacheGb, servers,
readWriteRatio: reads / writes,
};
}
const result = estimate({
dau: 2_000_000,
readsPerUserPerDay: 30,
writesPerUserPerDay: 0.2,
peakMultiplier: 3, // ASSUMPTION: read it off your own traffic graph
originalKb: 1_000,
variantsKb: 150,
metadataKb: 1,
servedKb: 150,
retentionYears: 5,
replicas: 3,
hotFraction: 0.2, // the 80/20 heuristic, not a measurement
perInstanceRps: 500, // ASSUMPTION: replace with a load-test number
targetUtilisation: 0.5,
});
for (const [name, value] of Object.entries(result)) {
console.log(name.padEnd(18), Number.isInteger(value) ? value.toLocaleString("en-US") : value.toFixed(2));
}Menjalankannya dengan Node menghasilkan output ini. Tidak ada pembulatan manual: bilangan bulat dicetak dengan pemisah ribuan dan sisanya dua desimal.
$ node estimate.ts
reads 60,000,000
writes 400,000
avgReadQps 694.44
avgWriteQps 4.63
peakReadQps 2083.33
peakWriteQps 13.89
newGbPerDay 460.40
rawTb 840.23
replicatedTb 2520.69
ingressMBps 15.97
ingressMbps 127.78
egressMBps 312.50
egressGbps 2.50
metadataCacheGb 12
servers 9
readWriteRatio 150Enam belas baris itu diringkas menjadi delapan langkah beserta rumusnya, sehingga Anda bisa mengulang hitungan di kertas dan mencocokkan script dengannya:
| Langkah | Rumus | Hasil photo-sharing |
|---|---|---|
| Request per hari | DAU x aksi per pengguna | 60.000.000 read, 400.000 write |
| QPS rata-rata | request per hari / 86.400 | 694,44 read, 4,63 write |
| Peak QPS | rata-rata x peak multiplier 3 | 2.083,33 read, 13,89 write |
| Storage per hari | write x 1.151 KB | 460,40 GB |
| Storage selama retention | per hari x 365 x 5 tahun x 3 salinan | 840,23 TB mentah, 2.520,69 TB direplikasi |
| Egress peak | peak read QPS x 150 KB x 8 | 312,50 MB/s, 2,50 Gbps |
| Cache metadata | 0,2 x read per hari x 1 KB | 12 GB |
| Application server | peak QPS / (500 x 0,5) | 9 |
Baca hasilnya sebagai arsitektur, bukan spesifikasi. Sekitar 2.100 request per detik saat peak itu sederhana. Rasio read 150 banding 1 mendukung cache dan CDN. Sekitar 2,5 petabyte mendukung object storage. Egress 2,5 Gbps adalah angka yang memaksa adanya CDN. Perhatikan bahwa tidak satu pun kesimpulan ini bergantung pada digit ketiga yang persis; masing-masing akan bertahan walau input meleset 30 persen.
Kerjakan daftar ini berurutan dan tulis tiap asumsi sebelum dipakai:
Ada empat kesalahan yang berulang. Mencampur byte dan bit mengubah 2,5 Gbps jadi 312 Gbps atau 0,3 Gbps. Lupa replikasi membuat storage terlalu kecil sebesar jumlah replika. Menghitung dari rata-rata, bukan peak, membuat layanan tumbang tepat saat paling dibutuhkan. Dan memperlakukan estimasi sebagai spesifikasi membekukan tebakan menjadi kontrak; tinjau ulang tiap asumsi yang ditandai begitu traffic nyata ada.
Tulis asumsinya, turunkan rantainya, tandai setiap tebakan, dan simpan outputnya sebagai order of magnitude. Tujuan estimasi bukan angkanya, melainkan keputusan yang didukungnya: satu box atau satu fleet, database atau object storage, RAM atau CDN. Saat metrik nyata datang, ganti asumsi bertanda satu per satu, mulai dari peak multiplier dan throughput per instance.
Sumber dan referensi