Estimation in the interview
Estimation earns its keep in the interview only when a number changes the design. Estimate the scale that matters, read whether the interviewer wants the math or the conclusion, and convert estimates into capacity — servers, storage, bandwidth — forced by arithmetic.
Two candidates get the same prompt. The first fills the whiteboard with arithmetic — average tweet length in bytes, the exact seconds in a day, a six-digit QPS — and forty minutes later has a beautiful set of numbers and no architecture. The second writes four numbers, says “300K read QPS, so a single database is out — I need a cache and a fan-out read path; storage is dominated by media at ~50 PB, so object storage plus a CDN,” and starts drawing. Same math, opposite outcomes. The first treated estimation as the goal; the second treated it as the lever — every number existed only to force a decision about the next box.
Estimation is a means, not the show
You already know how to estimate from the scalability unit’s back-of-the-envelope lesson: powers of two, Jeff Dean’s latency numbers, round to one significant figure, size for the peak. This lesson is about when and why to deploy that skill inside an interview — because the most common estimation failure in an interview is not bad arithmetic. It’s doing arithmetic that doesn’t matter.
A number earns its place on the whiteboard only if it would change the design. “This service stores about 2 KB per record” is trivia until you multiply it out and discover it’s 5 PB over the retention window — now it’s a decision: object storage, not a relational DB; tiered storage, not all-hot. The senior move is to estimate toward a conclusion: every figure is a question (“does this fit on one box, or do I need a fleet?”) whose answer picks the next component. If a number can’t change any decision, don’t compute it.
Which numbers change the design
A small set of estimates flips architectures. Learn to reach for these, and to skip the rest:
- Read QPS at peak. This decides whether a single primary database can serve reads (low-thousands of QPS) or whether you need replicas, a cache, or fan-out. It is usually the first design-changing number.
- Write QPS at peak. A single primary handles low-thousands of writes/sec; tens of thousands forces sharding or a different store. This is the number that decides whether the data tier is simple or hard.
- Storage over the retention window, split by data class. Text vs media often differ by 100×; the dominant class picks the storage technology (relational vs object store + CDN).
- Hot working-set size. If the hot set fits in one node’s RAM (~256 GB), a single cache node works; above it, you shard the cache.
- Egress bandwidth at peak. Peak read QPS × average response size tells you the CDN bill and whether one NIC can serve it.
Together, these five numbers cover every tier your architecture can bend at: read QPS sizes the cache, write QPS decides sharding, storage picks the storage class, hot-set size sizes the cache nodes, and bandwidth picks the CDN. Skip any one and you’re asserting a design decision without arithmetic backing it — the interviewer will notice. Notice these map one-to-one onto the design’s pressure points — the data tier, the cache tier, the delivery tier. You estimate the four-or-five numbers that sit on the boundary between “one box” and “a fleet,” because those are where the architecture bends.
▸Why this works
Why estimate at all in an interview, rather than just asserting “it’s high scale, so we’ll shard”? Because the interviewer is probing whether your decisions are grounded or cargo-culted. Anyone can say “add a cache.” The signal is whether you can say “300K read QPS against a store that does ~5K QPS per node means I need ~60 read replicas or, better, a cache that absorbs 95% of reads so I need only a handful of nodes.” The number is what separates a real engineer from someone reciting patterns. It also protects you from over-building: the estimate that says “actually this is only 200 QPS” is what stops you from sharding a database that fits comfortably on one box — the gold-plating failure from the requirements lesson, now caught by arithmetic.
Read the interviewer: math or conclusion?
A subtle interview skill is calibrating how much arithmetic to show. Interviewers fall on a spectrum, and the same detailed derivation that one wants is exactly what bores another into a “let’s move on.”
- Some want to see the mechanics — they’re checking you can actually do the math, convert daily to per-second, apply a peak multiplier, round honestly. Show your working.
- Many want the conclusion — they trust you can multiply, and they want to know what the number means for the design. Give the result and the decision it forces in one breath: “~10K writes/sec peak, which is past a single primary, so I’ll shard by user ID.”
Watch for the cues. If the interviewer leans in and asks “how did you get that?”, they want the derivation. If they nod and glance at the clock, give conclusions and bank the time for the design and deep-dive — the parts that actually differentiate candidates. Spending fifteen minutes deriving a number to three significant figures is itself a red flag: it signals you can’t tell a load-bearing calculation from a vanity one, and it burns the budget you needed for the hard part.
From estimate to capacity
The payoff of an estimate is capacity: turning a load number into a count of servers, gigabytes, and gigabits you can put on the diagram. The conversion is mechanical once you have the per-node throughput.
servers = peak QPS / per-node QPS (round up, then add headroom)
storage = object size × write rate × retention window (split by data class)
bandwidth = peak read QPS × avg response size
cache = hot-set size → fits one node's RAM? else shardWorked example, building on the design-a-Twitter estimate from the scalability unit: ~10K writes/sec peak, ~300K reads/sec peak, ~50 PB media over 5 years. Convert:
- App/read servers. If one node serves ~5K read QPS, 300K / 5K = 60 nodes — but most reads should hit a cache, so the real number is “a cache cluster holding the hot timeline set, plus a handful of origin nodes for misses.” The raw 60 is the upper bound that justifies the cache.
- Write path. 10K writes/sec is past a single primary’s comfortable low-thousands, so shard — the estimate just sized the data tier. This is the number that forced the hardest decision in the whole design, and you got it before drawing anything.
- Storage. ~50 PB of media → object storage (S3-class) fronted by a CDN, not a database; ~0.5 PB of text → a sharded relational or wide-column store. The estimate told you the two different storage technologies the design needs.
- Bandwidth. 300K reads/sec × ~5 KB = ~1.5 GB/s ≈ 12 Gbps egress — fine across a CDN fleet, but it puts a real cost on the bill and tells you a single 10 Gbps NIC won’t serve it.
▸Common mistake
The estimation mistake that quietly wrecks the design is sizing on the average and ignoring the peak — the same trap as the scalability unit, but it bites harder in an interview because the interviewer is looking for it. You compute 3,000 writes/sec average, declare a single primary fine, and the interviewer asks “what about the evening peak?” — at 3× that’s 9–10K writes/sec, past one primary, and your whole data tier was wrong. Always carry a peak-to-average multiplier (start at 3× for consumer apps), and remember the second-order trap: during an incident, client retries add load exactly at the peak, so a system sized for the average doesn’t just degrade — it enters a retry storm and collapses. Estimate the peak, and estimate it with retries in mind.
Mid-interview you've established ~8,000 writes/sec at peak against a store where one primary comfortably does ~3,000 writes/sec. What is the right thing to say next?
The interviewer nods quickly through your QPS math and glances at the clock. What does this signal, and how should you adjust?
In an interview, a number belongs on the whiteboard only if it would _______ the design — every figure should answer a question like 'one box or a fleet?' whose answer picks the next component; arithmetic that decides nothing is wasted time.
- 01Which numbers change the design, and why estimate those specifically?
- 02How do you read whether the interviewer wants the math or the conclusion?
- 03How do you convert an estimate into capacity, and what's the peak trap?
You learned how to estimate in the scalability unit; this lesson is when and why inside an interview. The governing rule: estimate only the numbers that change the design — peak read QPS, peak write QPS, storage over the retention window (split by data class), hot-set size, and peak bandwidth — because each sits on the boundary between “one box” and “a fleet,” which is exactly where the architecture bends. Every figure should answer a question whose answer picks the next component; arithmetic that decides nothing is wasted time. Read the interviewer: some want the mechanics (show your working), most want the conclusion (state the number and the decision it forces in one breath), and deriving to three significant figures when they want to move on is a red flag. Finally, convert estimates into capacity — servers = peak QPS / per-node throughput, storage = size × rate × retention, bandwidth = QPS × response size — so the boxes on your diagram are forced by arithmetic, not asserted. And always size for the peak, not the average, with retry storms in mind: the number that says “~10K writes/sec at peak” is the one that forces the sharded data tier, the hardest decision in the design, before you’ve drawn a single box. Now when you sit down to estimate, ask for each number: what design decision does this force? If you can’t answer, don’t compute it.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.