The Fermi Estimation Method

Get to a defensible number in under five minutes

Fermi estimation is the skill of getting a number that is right to within one order of magnitude, fast, by decomposing a big unknown into small quantities you are willing to assume. The physicist Enrico Fermi famously estimated the yield of a nuclear test by dropping bits of paper and watching how far the blast pushed them. In a system design interview the same move applies: you never actually know the QPS, so you build it out of assumptions you state out loud.

The process matters more than the precision. Four rules:

1. Decompose the unknown into things you can assume (users, actions per user, object sizes).
2. Write down every assumption explicitly so the interviewer can challenge one number, not the whole result.
3. Label units on every line (requests/day, bytes/object, seconds). Most estimation mistakes are unit mistakes.
4. Round aggressively to powers of ten. 86,400 seconds/day becomes 10^5. You are choosing a sharding strategy, not filing taxes.

Worked example

Suppose 50M daily active users, each doing 10 reads and 1 write per day.

reads/day  = 50M x 10 = 500M   = 5 x 10^8
writes/day = 50M x 1  =  50M   = 5 x 10^7
seconds/day ~= 86,400          ~= 10^5

avg read QPS  = 5 x 10^8 / 10^5 = 5,000
avg write QPS = 5 x 10^7 / 10^5 =   500

Average is not what your capacity must survive. Real traffic is peaky: a diurnal curve plus launch spikes. A 2x to 3x peak multiplier over the daily average is the standard defensible assumption. So plan for roughly 15k peak read QPS and 1.5k peak write QPS.

Interview nuance: interviewers do not care whether you land on 5,000 or 6,200 QPS. They care that you can defend the shape of the calculation and that you convert average to peak. Saying "I will assume a 3x peak multiplier because of the daily traffic curve" scores; a single unexplained number does not.

Only compute what changes a decision

The last rule is the one that separates a senior answer: only compute a number if it changes a decision. Peak write QPS of 1.5k tells you a single well-tuned Postgres primary can likely absorb writes, so you may not need to shard yet. A read QPS of 15k tells you that you want a cache tier and read replicas. A daily storage number tells you whether you need object storage plus a sharded metadata DB. If a calculation cannot move the architecture, skip it.

assumptions  ->  arithmetic  ->  a number  ->  a design decision
   (state)        (round)        (label)         (justify)

Interview nuance: the classic failure here is analysis paralysis, spending eight minutes deriving storage to three significant figures while the design goes untouched. Estimate only enough to unblock the next decision, then move.

Recap: decompose into stated assumptions, label units, round to powers of ten, convert average to peak with a 2 to 3x multiplier, and compute only the numbers that change the architecture.