Back-of-Envelope Estimation
Quick math that changes design decisions — and when to skip it.
Back-of-envelope estimation is quick, aggressively rounded math that answers one question: does this design need to be distributed at all? The modern interview guidance is to skip ritual upfront arithmetic and calculate only at the moment a number decides something — and to say that policy out loud.
The animation walks the canonical calculation on a napkin. "100M daily active users x 1 feed read" scribbles itself, gets divided by the 86,400-seconds-per-day stamp (round it to ~100,000 — precision is noise here), and lands on roughly 1,200 requests per second. Then the scale balance appears: that 1,200 QPS sits on one side, and a card reading "a single Postgres handles ~50k simple transactions/sec" sits on the other. The balance tips decisively: one database with read replicas is fine. No sharding, no exotic stores.
Watch for two habits worth stealing. First, the rounding — every number is order-of-magnitude, because the decision only needs to know whether you are 10x under or 10x over a limit. Second, the conclusion is a design decision, not a number. "1,200 QPS" by itself impresses nobody; "1,200 QPS, so one database with replicas is fine" is the signal interviewers want. Also remember peak traffic runs 2-5x the average — state a multiplier before you conclude.