Loading…
Interviewers at Google, Meta, and Amazon expect capacity estimates in the first 10-15 minutes of a system design round. Change the inputs, watch the numbers move, and learn the formulas — every result shows how it was derived.
Posts, uploads, messages — anything that creates data.
Estimates are deliberately coarse — in an interview, round aggressively and state your assumptions out loud. Peak factor 3x and the 80/20 cache rule are conventions, not laws; say so when you use them.
Queries per second is daily volume divided by the 86,400 seconds in a day. With 10 million daily active users each writing 5 times a day, that is 50 million writes per day, or roughly 580 writes per second on average. Multiply by a peak factor of 2-3x for capacity planning, because traffic concentrates around daily peaks. In interview math, treat 86,400 as "about 100K" — 50M / 100K is an instant 500 QPS.
Most systems read far more than they write. Instead of estimating reads independently, state a read:write ratio and multiply: a URL shortener is roughly 100:1 (each short link is created once, then clicked many times), a social feed closer to 10:1, and a logging pipeline nearly 1:1. The ratio you choose drives every downstream decision — read replicas, caching, and CDN placement.
Daily storage growth is writes per day multiplied by average payload size. 50 million writes of 2 KB each is about 100 GB per day, or about 36 TB per year. Multiply by the replication factor (3x is the common default in distributed storage) for the real disk footprint, and by the retention period if data expires.
Roughly 80% of reads hit about 20% of the data. Sizing a cache at 20% of the daily read volume is the standard interview heuristic — it tells you whether the hot set fits in memory on a handful of machines, which decides between a simple cache-aside layer and something more elaborate.
For worked examples, rounding tricks, and how to present these numbers in the interview itself, read the companion guide: Back-of-the-Envelope Estimation: Formulas, Worked Examples, and Latency Numbers.
It is a quick, order-of-magnitude calculation of a system's traffic (QPS), storage, and bandwidth from simple inputs like daily active users and request size. Interviewers use it to check that your architecture decisions — sharding, caching, CDN, replication — are justified by the actual numbers rather than guessed.
Four cover most interviews: QPS = (DAU x actions per user) / 86,400 seconds; peak QPS = average x 2-3; storage per day = writes per day x payload size; cache size = roughly 20% of the daily read volume (the 80/20 rule). Round aggressively — 86,400 is 'about 100K seconds' in interview math.
Order of magnitude is enough. Interviewers care that you state assumptions clearly, keep units consistent, and land within a factor of ten — not that you produce exact figures. Saying '10 million DAU times 5 writes is 50 million writes a day, call it 600 writes per second' is exactly the expected style.
Traffic is not uniform across the day — most consumer systems see daily peaks 2-3x their average as usage concentrates in evenings and events. A 3x peak factor is the common interview convention; state it as an assumption, since real peak-to-average ratios vary by product.
Every TierOnePrep system design walkthrough includes the capacity estimation step — practice deriving these numbers where they belong, between clarifying requirements and drawing the architecture.