Back-of-the-Envelope Estimation

Back-of-the-envelope estimation is not about precision — it is about finding out, in under two minutes, whether a design is off by an order of magnitude before you commit to it. The method is always the same: start from a number the prompt gives you or you can defend as an assumption (daily active users, for instance), round aggressively to the nearest convenient power of ten, and multiply through to the figure you actually need. A candidate who says "100 million daily users, each posting roughly once a day, so about 100 million writes a day, call it 1,200 writes a second" has done more useful work in fifteen seconds than one who spends three minutes computing 1,157 writes a second to the exact decimal. The rounded number is what drives every later decision — whether one database node is plausible, whether a queue is needed, whether a cache is worth the complexity.

The standard conversion is daily active users (DAU) times actions per user per day, divided by the number of seconds in a day — about 86,400, worth memorizing as "roughly 100,000" for a first pass. 100 million DAU at one write each gives 100 million ÷ 86,400 ≈ 1,160 writes/sec average. Average is rarely the number that matters: traffic is not flat across the day, and a peak-to-average ratio of 2–3× is a reasonable default to state explicitly rather than assume silently. A system built for "1,200 writes/sec average" should actually be sized for something closer to 3,000 writes/sec at peak. Reads usually dwarf writes — a social feed might see 100 reads for every write — so compute the two separately rather than assuming symmetry; a read-heavy design wants a cache and read replicas long before it needs write sharding.

Storage follows the same pattern: estimate the size of one record, multiply by how many are created per day, multiply by how long they must be kept. A short-link record at roughly 500 bytes, created 100 million times a day, kept for five years, comes out to about 500 B × 100M × 365 × 5 ≈ 90 TB — enough to know immediately that a single machine's disk will not hold it, and that partitioning is a real requirement, not a nice-to-have. Bandwidth is QPS times average payload size in each direction; a redirect service returning a few hundred bytes at 1,200 requests/sec needs well under 1 MB/sec of egress, which rules out network bandwidth as a bottleneck and points the conversation toward where the real limit sits — usually disk I/O or a single database connection pool.