Ten to fifteen minutes into most system design rounds at Google, Meta, and Amazon, the interviewer expects you to stop talking about features and start talking about numbers: how many queries per second, how much storage per year, how big a cache. This is back-of-the-envelope estimation (you will also see it written back-of-envelope calculation or capacity estimation — same skill), and it is one of the most learnable parts of the entire interview.
The good news: four formulas, a handful of latency numbers, and two rounding tricks cover nearly every estimation an interviewer will ask for. This guide teaches all of them with worked examples, and every formula here matches TierOnePrep's free back-of-the-envelope calculator, where you can move the inputs and watch the numbers respond.
Why Interviewers Ask for Estimates
Interviewers do not care whether your answer is 580 QPS or 600 QPS. They ask for estimates because the numbers justify the architecture. Sharding is only justified if one machine cannot hold the data; a cache layer is only justified if the hot set is large enough to matter and small enough to fit in memory; a CDN is only justified by egress volume and geographic spread. A candidate who proposes "we'll shard the database and add Redis" without numbers is pattern-matching. A candidate who says "100 GB a day is 36 TB a year — that's beyond one node within a quarter, so we shard by user ID from day one" is engineering.
Estimation also demonstrates three habits interviewers score directly: stating assumptions out loud, keeping units consistent, and sanity-checking results against reality.
Google's SRE organization formalized this numbers-first discipline as NALSD — Non-Abstract Large System Design: a design is not finished while it is abstract, and every architecture must be iterated into concrete machine counts, disk throughput, and per-replica QPS until the arithmetic proves it works. NALSD-style rounds are standard in Google SRE interview loops, and every formula in this guide is exactly the toolkit they test.
The Four Formulas That Cover Almost Every Interview
1. Average QPS = (daily active users × actions per user per day) / 86,400 seconds
2. Peak QPS = average QPS × 2–3 (traffic concentrates around daily peaks)
3. Storage per day = writes per day × average payload size (then × 365 for a year, × replication factor for real disk)
4. Cache size ≈ 20% of the daily read volume (the 80/20 rule: ~80% of reads hit ~20% of the data)
Reads usually come from a ratio rather than a separate estimate. State a read:write ratio and multiply: a URL shortener is roughly 100:1 (a link is created once, clicked many times), a social feed closer to 10:1, a logging pipeline nearly 1:1, and CDN-served content can reach 1000:1. The ratio you pick drives every downstream decision — read replicas, caching, and CDN placement — so say it explicitly and justify it in one sentence.
The peak factor and the 80/20 rule are conventions, not laws. Interviewers know this; naming them as assumptions ("I'll take peak as 3x average, which is typical for consumer products") earns credit rather than losing it.
Interview Math: Round First, Calculate Second
Nobody expects long division at a whiteboard. Two tricks make the arithmetic instant:
Second, learn the unit ladder so storage math is multiplication of small numbers:
| This × That | Result | Example |
|---|---|---|
| 1 million × 1 KB | 1 GB | 1M log lines of 1 KB = 1 GB/day |
| 1 million × 1 MB | 1 TB | 1M photos of 1 MB = 1 TB/day |
| 1 billion × 1 KB | 1 TB | 1B events of 1 KB = 1 TB/day |
| 2^10 ≈ 10^3 | KB→MB→GB→TB | each step is ×1,000 in interview math |
Worked Example 1: URL Shortener (Read-Heavy, 100:1)
The URL shortener design question is a classic opener, and its estimation is the cleanest illustration of the read-heavy pattern. Assume 1 million new short links per day, each redirect record about 500 bytes, and a 100:1 read:write ratio.
- Write QPS: 1M / 86,400 ≈ 12 writes/sec average — trivial for any database.
- Read QPS: 12 × 100 = 1,200 reads/sec average, ≈ 3,500/sec at a 3x peak.
- Storage: 1M × 500 bytes = 500 MB/day ≈ 180 GB/year, ≈ 550 GB with 3x replication. Years of runway on a single node.
- Cache: daily read volume is 100M reads × 500 bytes = 50 GB; 20% of that is 10 GB — the entire hot set fits in memory on one cache node.
Notice what the numbers did: they killed complexity. No sharding, no exotic storage — the design conversation moves to key generation and redirect latency, because the estimate proved capacity is a non-problem. Reaching that conclusion from the numbers is precisely what the interviewer wants to see.
Worked Example 2: Social Feed (Balanced, 10:1)
Now the defaults from the calculator, with a feed-like ratio — the same shape as the Twitter news feed question. Assume 10 million DAU, 5 writes per user per day, 2 KB average payload, 10:1 reads.
- Write QPS: 10M × 5 = 50M writes/day ≈ 580/sec average, ≈ 1,700/sec peak.
- Read QPS: 580 × 10 = 5,800/sec average, ≈ 17,000/sec peak.
- Storage: 50M × 2 KB = 100 GB/day ≈ 36 TB/year, ≈ 110 TB with 3x replication — now sharding and tiered storage are justified, not assumed.
- Bandwidth: egress ≈ 5,800 × 2 KB ≈ 12 MB/s average — modest, so the interesting egress problem is fan-out amplification, not raw bytes.
- Cache: daily read volume ≈ 1 TB; 20% ≈ 200 GB — too big for one node, fine for a small sharded cache tier.
Same four formulas, opposite conclusion: this system earns its distributed architecture. Being able to run both examples end-to-end in under three minutes each is a realistic bar for interview readiness.
The Latency Numbers That Anchor Your Estimates
Capacity says how much; latency says how fast. A few anchor numbers let you sanity-check any design decision (full table, with log-scale bars and notes, on the free latency numbers reference):
| Operation | Latency | If 1 ns were 1 second |
|---|---|---|
| Main memory reference | 100 ns | ~1.5 minutes |
| SSD random read (4 KB) | 16 µs | ~4.5 hours |
| Round trip within a datacenter | 500 µs | ~5.8 days |
| Read 1 MB over a 1 Gbps network | 10 ms | ~4 months |
| Round trip across an ocean | 150 ms | ~4.8 years |
Two conclusions carry most interviews: memory is roughly 160x faster than SSD for random reads, which is why in-memory caches exist at all; and cross-region round trips are physics, which is why CDNs and regional replicas exist. Citing the relevant number when you propose a cache or a CDN turns an assertion into an argument.
How to Present Estimates in the Interview
Estimation sits between requirements and architecture — right after the clarifying questions phase (covered in depth in how to start a system design interview). The presentation pattern that works:
- Propose the inputs and get agreement. "Shall we say 10 million DAU, 5 posts a day, 2 KB each?" If the interviewer gives no numbers, offering defensible ones is itself being evaluated.
- Narrate the arithmetic, rounded. "50 million a day over roughly 100K seconds — call it 500 writes a second."
- Sanity-check the result. "500 QPS of writes is comfortable for a single primary; 36 TB a year is not comfortable for a single node."
- Convert every number into a design decision. This is the step most candidates skip. An estimate that doesn't change the design was wasted airtime.
Spend five minutes, not fifteen. If the interviewer wants deeper math (they sometimes probe storage retention or bandwidth costs), they will ask — follow their lead rather than exhaustively computing everything.
Common Mistakes
- False precision. Reporting "578.7 QPS" signals you missed the point. Round aggressively and say you are rounding.
- Silent assumptions. The number is fine, but nobody heard where it came from. Every input gets one sentence.
- Unit drift. Mixing per-day and per-second, or bits and bytes, halfway through. Write units down.
- Estimating without consequence. Producing numbers and then designing as if you hadn't. Tie each estimate to a decision.
- Forgetting replication and growth. Raw yearly storage × 3 replicas × a few years of growth is often 10x the naive figure — the difference between "one big node" and "shard now."
Where to Practice
Estimation improves fast with repetition because the formulas never change — only the inputs do. Three free ways to drill it:
- The back-of-the-envelope calculator — change DAU, payload, and ratio; every result shows its formula.
- The system design fundamentals quiz — estimation and scaling questions with explanations.
- Any system design question on TierOnePrep — every interactive walkthrough includes a capacity estimation step between clarifying requirements and drawing the architecture, so you practice the math where it actually happens.
FAQ
Is back-of-the-envelope estimation still asked in 2026? Yes — it remains a standard component of system design rounds at FAANG (Facebook/Meta, Apple, Amazon, Netflix, Google) and AI-first companies alike, typically in the first third of the interview. AI-infrastructure questions have made it more relevant: GPU serving costs and token throughput estimates are the same skill with new units.
How accurate do my estimates need to be? Order of magnitude. Interviewers check that assumptions are stated, units are consistent, and the result lands within a factor of ten. Rounding 86,400 seconds to 100K is expected style, not sloppiness.
Should I memorize the latency numbers table? Memorize five anchors: memory ~100 ns, SSD random read ~16 µs, same-datacenter round trip ~500 µs, 1 MB over a 1 Gbps link ~10 ms, cross-ocean round trip ~150 ms. The full reference has the rest with context for when each matters.
What if the interviewer doesn't give me any numbers? Propose your own and ask for agreement — "assume 10 million DAU?" Choosing defensible inputs is part of the assessment. Real systems' public figures (millions of DAU for a mid-size product, billions for the largest) are fine starting points.
How long should the estimation section take? Five to ten minutes of a 45-minute round. Compute traffic, storage, and the cache/bandwidth numbers that affect your design, state the design consequences, and move on. Depth on request.