On this page
Description
Two designs for the same service: one shards its database across 64 nodes and puts Kafka in front of every write; the other runs on one database with two replicas and a cache. Which is right? Neither, until you know the numbers. At 40 writes a second the first design is months of unnecessary work; at 400,000 the second falls over on day one.
Back-of-the-envelope estimation is how you find out which world you're in - in about five minutes, with round numbers. Interviewers don't want precision. They want to watch you turn "500 million users" into "about 60,000 reads a second, 50 times the writes, 30 TB a year", and then use those numbers to decide what to build. Step by step:
- A handful of numbers worth remembering - time, data sizes, latencies.
- Turning users into requests per second, including the peak.
- Storage and bandwidth.
- How many servers, and why you never plan for 100% busy.
- Latency budgets, and a worked estimate from start to finish.
- Turning each number into a design decision.
Numbers to keep in your head
Time: a day is 86,400 seconds - round it to 10^5. A month is about 2.6 million seconds, a year about 31.5 million.
| Per day | Per second (average) |
|---|---|
| 1 million | ~12 |
| 100 million | ~1,200 |
| 1 billion | ~12,000 |
Powers of ten for data: KB = 10^3, MB = 10^6, GB = 10^9, TB = 10^12, PB = 10^15 bytes. A short text record is ~1 KB; a photo ~200 KB-2 MB; a minute of HD video ~50-100 MB.
Latency, order of magnitude:
| Operation | Time |
|---|---|
| Read from main memory | ~100 ns |
| Random read from an SSD | ~100 µs |
| Round trip within a data center | ~0.5 ms |
| Read 1 MB sequentially from memory | ~0.1 ms |
| Round trip US East ↔ Europe | ~70-100 ms |
| Round trip US ↔ Australia | ~150-200 ms |
The ratios matter more than the digits: memory is ~1,000x faster than SSD, and a cross-ocean round trip costs as much as hundreds of in-data-center ones.
Requests per second
Daily active users × actions per user ÷ 86,400. For a photo app with 50 million daily users who each open the feed 10 times: 500 million reads a day ÷ 86,400 ≈ 5,800 reads/s. Traffic isn't flat - evenings and events spike it - so size for a peak of 2-3x: about 15,000 reads/s. Do the same for writes: 5 million uploads a day is ≈ 60/s. A 100:1 read:write ratio tells you where caching and replicas go.
Storage
Items per day × size × retention, then × the replication factor (typically 3 copies for durability). 10 million photos a day at 2 MB is 20 TB a day - 7.3 PB a year, 36.5 PB over five years, about 110 PB with three copies. Numbers like that say object storage, not a database, and they say to store several resized versions only if the product needs them.
Bandwidth
Concurrent users × bitrate. One million people watching 5 Mbps video is 5 × 10^12 bits/s = 5 Tbps (625 GB/s). No origin serves that; it's what CDNs are for. Watch bits versus bytes - network speeds are in bits, storage in bytes, a factor of 8.
Server counts
Peak load ÷ per-server capacity, at a utilization target that leaves headroom. If one app server handles about 2,000 requests/s flat out and the peak is 15,000/s, 8 servers would run at 100% with no room for a spike or a failure. At a 60% target that's 15,000 ÷ 1,200 ≈ 13 servers, plus one spare so losing a node doesn't overload the rest - about 14. The per-server figure is itself an estimate (it depends on the work per request); say so and move on.
Latency budgets
Sequential calls add up. A page that makes 20 database queries one after another, at ~5 ms each, spends 100 ms waiting - no CPU upgrade changes that. The fixes are structural: batch the queries, run independent ones in parallel, cache the result, or move the data closer. Likewise, three sequential calls to a service in another region at ~70 ms each blow a 200 ms budget before any work is done.
A worked estimate
The photo app from above, end to end - five minutes on a whiteboard:
| Quantity | Working | Result |
|---|---|---|
| Feed reads | 50 M users × 10 a day ÷ 86,400 | ~5,800/s average, ~15,000/s peak |
| Uploads | 5 M a day ÷ 86,400 | ~60/s average, ~150/s peak |
| Read:write | 5,800 ÷ 60 | ~100:1 |
| Photo storage | 5 M × 2 MB × 365 days | ~3.65 PB a year, ~11 PB with 3 copies |
| Metadata | 5 M × 1 KB × 365 | ~1.8 TB a year - fits a database |
| App servers | 15,000 ÷ (2,000 × 60%) + 1 | ~14 |
Two decisions fall straight out: photo bytes go to object storage behind a CDN, and the metadata stays small enough for a replicated relational database with a cache in front.
Using the numbers
Every estimate should end in a decision:
- 60 writes/s → a single primary handles writes; don't shard for write throughput yet.
- 15,000 reads/s of a skewed workload → a cache in front of the database.
- 110 PB of photos → object storage, not database rows.
- 5 Tbps of video → a CDN.
(The thresholds are rough: what one database primary sustains depends on the hardware and the work per write. Treat them as the point where you'd start measuring, not a law.)
Going further. The deep dive (next tab) adds the quantitative tools behind capacity planning: Little's law, why latency explodes near full utilization, how tail latency compounds when a request fans out, how skewed traffic decides cache size, and how to sanity-check an estimate.
Check yourself
Try to answer before opening each one - recalling beats re-reading.
1. 200 million daily users each post twice a day. Roughly how many writes per second at peak?
Show answer
400 million posts a day ÷ 86,400 ≈ 4,600/s on average; at a 2-3x peak, about 10,000-14,000/s. Say "about 10,000 writes a second at peak" and move on.
2. Why multiply storage by 3?
Show answer
Durable storage keeps several copies - typically three, on different machines or zones - so a disk or node failure loses nothing. The raw data size understates what you provision by that factor.
3. A request makes 4 sequential calls within the data center (~0.5 ms each) and 1 call to another continent (~100 ms). Where do you look first to cut latency?
Show answer
The cross-continent call - it's ~98% of the waiting. Serve that data from the same region (replicate or cache it), or take the call off the request path.
Key takeaways
- 1 million a day ≈ 12 a second; size for a 2-3x peak.
- Storage = items × size × retention × replication (usually 3).
- Bandwidth = concurrent users × bitrate; terabits mean a CDN. Bits ≠ bytes.
- Servers = peak ÷ (per-server capacity × ~60%), plus a spare.
- Memory ~100 ns, SSD ~100 µs, in-DC round trip ~0.5 ms, cross-ocean ~100 ms: count the sequential round trips.
- One or two significant figures - and every number ends in a decision.