Back-of-the-Envelope Estimation for System Design Interviews

Back-of-the-envelope estimation is the skill of quickly approximating a system's scale — requests per second, storage growth, bandwidth — using rough math. In a system design interview it's not busywork: the numbers decide your design. Whether you need one database or a sharded fleet, whether a cache is optional or essential, whether data fits in memory — all fall out of a two-minute estimate. Here's how to do it well.

Why interviewers care

Estimation shows you can reason about magnitude before committing to an architecture. A candidate who says "I'd shard the database" without knowing whether the data is 3 GB or 3 PB is guessing. A candidate who estimates "~3 TB over five years — fits on one well-provisioned node with room to shard later" is engineering. You don't need precision; you need the right order of magnitude and the judgment to act on it.

The numbers to know

Powers of 2 → data sizes:

Power	Approx	Unit
2¹⁰	~1 thousand	KB
2²⁰	~1 million	MB
2³⁰	~1 billion	GB
2⁴⁰	~1 trillion	TB
2⁵⁰	~1 quadrillion	PB

Time conversions:

• 1 day ≈ 86,400 seconds (round to ~100,000 for fast math).
• 1 million/day ≈ ~12 per second. (Memorize this — it converts daily volumes to QPS instantly.)
• 1 billion/day ≈ ~12,000 per second.

Latency (order of magnitude): memory read ~100 ns · SSD read ~100 μs · same-datacenter round trip ~500 μs · cross-region round trip ~100 ms. Memory is ~100,000× faster than a cross-region hop — the reason caching and locality matter.

Rough sizes: a short text record (id + a few fields) ≈ hundreds of bytes; a typical web page ≈ ~100 KB–1 MB; a photo ≈ ~1 MB; a minute of video ≈ ~10–50 MB depending on quality.

A repeatable method

1. Start from users. Daily active users (DAU) is usually the anchor.
2. Convert to QPS. Actions per user per day × DAU ÷ 86,400. Then multiply by a peak factor (2–5×) — traffic isn't uniform.
3. Split reads vs. writes. State the ratio; it drives caching and replication decisions.
4. Estimate storage. Bytes per item × items/day × retention period.
5. Sanity-check against a single machine. A modern server handles thousands of QPS and has plenty of disk. If your numbers blow past that, you've justified sharding/replication. If not, don't over-engineer.

Round aggressively — 86,400 → 100,000, 1.7 → 2. Interviewers want the reasoning, not the decimals.

Worked example: a Twitter-like feed

Assume: 300 million DAU, each posts ~2×/day and opens their timeline ~10×/day.

• Writes (posts): 300M × 2 = 600M/day ÷ ~100K ≈ ~6,000 writes/sec average, ~20–30K/sec at peak.
• Reads (timeline opens): 300M × 10 = 3B/day ≈ ~35,000 reads/sec average, well over 100K at peak.
• Read/write ratio: ~5:1 here — reads dominate, so we should precompute timelines and cache heavily. (This is exactly why the Design Twitter answer pushes work to write-time.)
• Storage for posts: say 300 bytes/post × 600M/day ≈ 180 GB/day ≈ ~65 TB/year — clearly needs a distributed store, not one node.

Notice how the estimate directly produced the design decisions: precompute + cache (read-heavy), distributed storage (65 TB/year). That's the whole point.

Tips that make estimation land

• Say your assumptions out loud ("let's assume 300 million daily users") — interviewers care about the method, and they'll correct your inputs if needed.
• Round to clean numbers and use scientific-ish notation (6 × 10⁸) to avoid arithmetic slips.
• Always translate numbers into a decision — "that's ~65 TB/year, so a single database won't do; I'll shard by user ID."
• Don't over-invest. Two minutes is plenty. The estimate exists to guide the design, not to be exact.

The one-line version

Anchor on DAU → convert to peak QPS (× a peak factor) → split reads/writes → compute storage/year → compare to one machine to decide whether you need to scale out. Round hard, state assumptions, and turn every number into a design decision.

---

Estimation clicks when you do it out loud, under time pressure, on real problems. On Whitepad, a senior AI interviewer runs full system design mocks by voice and pushes you to justify the numbers behind your design — first mock free.