Back-of-the-envelope estimation for system design interviews
Most people don't fail capacity math because the arithmetic is hard. They fail because they do it silently, produce a number they can't defend, and then never use it again for the rest of the interview.
The math itself is trivial. The method is what's worth learning.
Why interviewers ask
Capacity estimation isn't a numeracy test. It's checking two things:
- Can you tell whether a design is physically possible before you commit to it?
- Do you know which constraint actually binds — storage, read throughput, write throughput, or bandwidth? A candidate who estimates 30,000 reads/sec and 200 writes/sec has learned something that changes the design. A candidate who computes petabytes of storage and then never mentions it again has just performed arithmetic.
Round aggressively
Precision is a trap. You're not producing a capacity plan; you're finding the order of magnitude.
The single most useful substitution:
1 day = 86,400 seconds ≈ 10^5 seconds
That's a 16% error and it makes every subsequent division doable in your head. Nobody will challenge it. Everyone will notice if you spend forty seconds long-dividing by 86,400.
A few more worth having ready:
- 1 million requests/day ≈ 12/sec — round to 10
- 1 KB × 1 million = 1 GB
- 1 KB × 1 billion = 1 TB
- Peak traffic ≈ 2–3× average
- Replicated storage ≈ 3× raw ## Work in one direction
Users → requests → QPS → storage → bandwidth. Don't jump around. Say each assumption out loud and label it as an assumption, so the interviewer can correct you early rather than watch you build on sand.
A worked example
Say we're designing a social feed. Given: 100M daily active users.
Assumptions (stated, not smuggled in):
- Each user posts 0.2 times/day
- Each user reads their feed 10 times/day
- A post averages 1 KB including metadata
- A feed page shows 20 posts Writes
100M × 0.2 = 20M posts/day
20M / 10^5 = 200 writes/sec
Peak (3×) = 600 writes/sec
Reads
100M × 10 = 1B feed loads/day
1B / 10^5 = 10,000 reads/sec
Peak (3×) = 30,000 reads/sec
Storage
20M posts/day × 1 KB = 20 GB/day
× 365 = ~7 TB/year
× 3 (replication) = ~21 TB/year
Bandwidth at peak
30,000 reads/sec × 20 posts × 1 KB = 600 MB/s
Now the part that matters
Look at what those numbers rule out.
The read:write ratio is 50:1. That asymmetry is the whole design. It says: do the expensive work on the write path, because writes are rare and reads are constant. Fan out to precomputed feeds on write rather than assembling feeds on read.
Storage is ~21 TB/year replicated. That's unremarkable — a handful of machines. Storage is not your constraint, so don't spend interview time on sharding strategies for it.
600 MB/s of egress at peak is real but ordinary. A CDN and a cache layer handle it.
So the binding constraint is read QPS, and the design should be organised around absorbing it. That conclusion came directly from four lines of arithmetic, and it's the reason the arithmetic was worth doing.
The latency numbers that constrain design
Throughput math tells you how much. Latency numbers tell you what's possible at all. Rough current intuitions:
| Operation | Time |
|---|---|
| L1 cache reference | ~1 ns |
| Main memory reference | ~100 ns |
| NVMe SSD random read | ~50–100 µs |
| Round trip within a datacenter | ~0.5 ms |
| Disk seek (spinning) | ~5 ms |
| Round trip across a continent | ~150 ms |
The useful pattern isn't memorising the table — it's the ratios. Memory is roughly a thousand times faster than SSD. A cross-continent round trip is roughly three hundred times a within-datacenter one. That's why a design requiring three sequential cross-region calls inside a 200 ms budget is dead on arrival, and you can say so immediately.
Five mistakes that cost points
- Silent arithmetic. The interviewer can't grade what they can't hear. Narrate.
- Precision theater. Using 86,400 instead of 10^5 signals you've missed the point of the exercise.
- Computing a number and abandoning it. Every estimate should be followed by a sentence starting "which means…".
- Ignoring peak. Average load sizes nothing. Systems fail at peak.
- Forgetting the multipliers. Replication, indexes, and metadata overhead routinely triple raw storage.
Practicing it
The awkward thing about this skill is that it's hard to practise alone — you can do the arithmetic, but you can't easily tell whether your assumptions were reasonable or your conclusion was the right one to draw.
What helped me was working the same handful of scenarios repeatedly and forcing myself to write the "which means…" sentence after every number. The arithmetic gets automatic fast. The interpretation is the part that takes reps.
I built a small free calculator that takes daily active users, write rate, and payload size and returns QPS, storage, bandwidth, and cache estimates with every formula shown, so you can check your working rather than just the answer: tieroneprep.com/tools. No login. It sits alongside an interview prep site I run that does have a paid tier — the tools don't.
If you've got a rule of thumb that's saved you in an interview, I'd like to hear it.
Top comments (0)