What it is
Estimation questions ask you to size something — a request rate, a memory footprint, a server fleet, a latency budget, a bandwidth requirement — with no access to the real numbers. The technique is not a formula but a discipline: state each input assumption explicitly, chain them together with unit-consistent multiplication, round aggressively to powers of ten along the way, and finish by checking the result against something you actually know (a published figure, a physical limit, a familiar rule of thumb). The answer is an order of magnitude with a defensible derivation, not a precise number pulled from memory.
When it applies
- The interviewer asks "how many," "how much," or "how long" about a system at a scale too large to reason about directly — users, requests, bytes, servers, milliseconds.
- You need a number to unblock a design decision (does this fit on one machine, do we need to shard, is 300 ms achievable) rather than as an end in itself — estimation is almost always a means to a design conclusion, not the whole answer.
- It does not apply once the question is really about correctness or algorithmic behavior rather than scale — don't reach for a Fermi estimate when the interviewer wants a data structure or a proof; and don't stop at a bare number when the prompt clearly wants the follow-on decision it implies (fits on one box, needs a cache, needs a CDN).
Tells in the problem
- "Estimate how many X per second/day" — a rate question: derive users × actions-per-user first, then divide by seconds in a day, then apply a peak-to-average ratio.
- "How much memory/storage would this need" — a count-times-size question: get the entry count and the per-entry byte cost (including structural overhead, not just payload) as two separate numbers before multiplying.
- "Break down where the time goes" or "is this latency budget achievable" — a sum of stage costs where some stages are sequential and some are parallel; round-trip counting matters more than raw computation time.
- "How many servers/machines do we need" — a throughput-per-unit question: capacity per server × utilization target, divided into peak demand, then multiplied by headroom factors (failure domain, growth, rollout).
- Any prompt that gives you a familiar company or product name and a plausible-sounding population figure — treat the given number as an input to derive from, not a fact to quote; deriving 8 billion daily searches and then noting it matches the public figure is stronger than starting from the public figure.
The classic mistake
The recurring failure is conflating a flow with a stock, or an average with a peak, without noticing the switch — using a per-day total as if it were a concurrent or per-second figure, or sizing a system for average load when the entire point of capacity planning is the busy hour. A closely related version is stopping at a raw payload size and forgetting that every real data structure (a hash table entry, a cache record, a network packet) carries overhead that can double or triple the naive count. Both mistakes are easy to make because the arithmetic still "works" and produces a plausible-looking number; the only defense is naming, out loud, whether each quantity is a rate or a total, an average or a peak, and a payload or a fully-accounted entry, before you multiply it into anything else.
Questions to start with
- Convert DAU to Concurrent Users — the cleanest example of the flow-versus-stock trap, solved with Little's law and a peak-to-average ratio.
- Estimate Search Engine QPS — the full chain from population down to backend fan-out, with a public figure available as a sanity check at the end.
- Estimate Memory for a URL Cache — entry count times per-entry bytes, including the structural overhead that's easy to forget, plus a probabilistic-structure trade-off.
- Break Down a Latency Budget — a sum of stage costs where distinguishing round trips from one-way transfer time is the entire exercise.
- Estimate Servers for an API Load — throughput-per-server derived from Little's law, then layered with utilization, failure-domain, and growth headroom.