Foundations of Scale
Back-of-the-envelope numbers
“Can one database handle this?” is not a feeling — it is arithmetic. With five numbers memorized and one recipe, you can answer it on a napkin in two minutes.
Most engineers guess. They argue for a cluster because it “feels big,” or panic over traffic that one laptop could serve. Estimation replaces the feeling with a number — and a number can be checked.
- Powers of two for data: KB ≈ a thousand bytes, MB ≈ a million, GB ≈ a billion, TB ≈ a trillion. Close enough for any design conversation.
- Latency intuition: reading from memory is ~100× faster than reading from SSD, and SSD is ~100× faster than a network round trip across the country. Think in orders of magnitude, not exact numbers.
- One day = 86,400 seconds ≈ 100,000 seconds. Rounding up makes every division in this lesson trivial.
- CPU cache reference: ~1 ns. This is your unit — everything else is measured against it.
- RAM read: ~100 ns — about 100× slower than cache. Still effectively free compared to anything below.
- SSD random read: ~100 µs — about 1,000× slower than RAM. This is why a cache hit and a database lookup are not the same thing.
- Disk seek on a spinning drive: ~1 ms — about 10× slower than SSD. Random I/O on HDD is the trap; sequential is fine.
- Network round trip inside one datacenter: ~0.5 ms. Cheap enough to chat — but not thousands of times per request.
- Cross-continent round trip: ~150 ms — about 300× a same-datacenter hop. This is physics, not engineering; only a CDN shortens it.
- Average QPS = daily active users × actions per user ÷ 86,400. That is how many requests per second your system must serve on a normal day.
- Peak QPS ≈ 2× average. Lunch hours, evenings, and launches concentrate traffic — design for the peak, not the average.
- Storage per day = number of writes × size of one record. Multiply by the retention days to get total storage.
Say 10M daily users, each sending 30 messages a day. Messages per day = 10M × 30 = 300M. Average QPS = 300M ÷ 86,400 ≈ 3,500 messages per second; peak ≈ 7,000. Now storage: 300M messages × 50 bytes of metadata each ≈ 15 GB per day. Keep everything for 5 years: 15 GB × 365 × 5 ≈ 27 TB. Every number here came from one multiplication or one division — no magic.
Say 10M daily users, each uploading 2 photos a day at ~2 MB apiece. Uploads per day = 10M × 2 = 20M photos. Ingress storage = 20M × 2 MB = 40M MB ≈ 40 TB of new data every day — and 40 TB × 365 ≈ 15 PB per year, before replicas. Write bandwidth = 40 TB ÷ 86,400 s ≈ 460 MB/s, call it ~500 MB/s on average — and about 1 GB/s at peak. Reads run about 10× the writes: 10 × 500 MB/s ≈ 5 GB/s served on average. Storage, not QPS, is what hurts here — and bandwidth is what you pay the cloud bill for.
Nobody wants the right number — they want to watch you reason. Whether the answer is 3,500 or 5,000 QPS changes nothing; whether it is 3,500 or 350,000 changes the whole design. Magnitude matters, precision doesn't.
Quick mental math: 2M daily users each load 10 pages — what is the average QPS and the peak? (2M × 10 = 20M requests/day; 20M ÷ 86,400 ≈ 230 QPS average, ≈ 460 at peak — one modest server handles it.)
Estimation is a recipe, not a talent: users × actions ÷ seconds for QPS, writes × size × days for storage, and peak is double the average. Round aggressively — you are choosing an architecture, not filing taxes.
Pick one system you work on today. Estimate its average QPS, peak QPS, and storage growth per month on a single page. You will probably discover it is either far smaller or far bigger than everyone assumed — both are useful.
Foundations of Scale