Why estimation comes first

An interviewer opens with estimation for the same reason a structural engineer starts with loads: every decision after it depends on the order of magnitude. A design that is right for ten thousand requests a second is wrong for ten, and wrong again for ten million. Getting the number roughly right is what makes the next forty minutes coherent.

Roughly right is the whole standard. Nobody is checking your arithmetic — they are checking whether you know which quantities matter, whether you remember that peak is several times average, and whether you can say “about ten million, call it twenty for headroom” without pretending to a precision the assumptions cannot support.

The five numbers that carry an estimate

Almost every capacity question resolves into the same handful of quantities, and the estimator above is only arithmetic on top of them.

• Daily actives, and actions each. Monthly actives are a vanity number; the ratio of daily to monthly is usually between a third and a half.
• The read-to-write ratio. Usually the biggest lever in the whole estimate and the one most often left unstated. A social feed is 100:1 or worse; a logging pipeline is the other way round.
• The peak multiplier. Human traffic is diurnal. A service sized for its daily mean falls over every evening, and two to three times average is the honest figure.
• Bytes per action. Including the indexes, which for key-value workloads are frequently larger than the data.
• Replication and retention. Both multiply storage, and both are forgotten in roughly half of all estimates.

A day is 86,400 seconds, which is 100,000

The single most useful approximation in this whole subject. Dividing by 100,000 is something you can do in your head while talking, and it is within 15% — far inside the precision your assumptions justify. Ten million actions a day is a hundred a second. A billion is ten thousand a second. Those two conversions cover most of what you will be asked.

Then run it

The part that separates an estimate from an understanding is what happens next. Take the number you just produced and push it through something that runs: autilisation curve at that server count, abalancer at that request rate, acache in front of that origin. Nearly everyone is wrong about where their own design breaks, and finding out costs a minute.