# Easier Back-of-the-envelope estimation Back-of-the-envelope estimation sounds like it needs a memorized chart of latency numbers. It does not. In an interview you are after one thing: the *order of magnitude* that tells you whether this fits on one machine or needs sharding, whether a cache is optional or mandatory, whether storage is gigabytes or petabytes. You get there with **one number and three steps** - and this post is the easy version, not a table you will never remember. This is part of the System Design Guide series. It slots in right after gathering requirements: once you know the scale, a few minutes of arithmetic turns it into the numbers that pick your architecture. ## The one number that matters Memorize this and you are most of the way there: > **A day has about 100,000 seconds.** (It is 86,400; round it to 10^5.) That single approximation gives you queries per second from any daily count by dividing: ```text QPS = events per day / 100,000 ``` So 100 million events a day is ~1,000 per second. 1 billion a day is ~10,000 per second. That is the whole trick for throughput. Everything else is a rough sense of sizes, not a lookup table: - **Data sizes go up by ~1000 each step:** KB -> MB -> GB -> TB -> PB. A text record is roughly 1 KB, a photo roughly 1 MB, a minute of video a few MB. You do not need exact figures; you need the right power of ten. - **Peak is about 2 to 3 times the average.** Traffic is not flat, so size for the peak. - **Reads usually outnumber writes,** often 10:1 or more. Estimate the two paths separately. - **The only latency fact you need:** memory is nanoseconds, disk and network are milliseconds - about a million times slower - and a cross-region round trip is roughly 100 ms. The lesson isn't a number, it's a rule: keep the hot path in memory, avoid disk and network round-trips. (If you ever want the full picture, the classic [latency numbers chart](https://colin-scott.github.io/personal_website/research/interactive_latency.html) has it, but you do not need to memorize it.) That is the entire cheat sheet. One number, one size ladder, a peak factor, a read/write skew, and a single latency rule. ## The method: three steps Every estimation is the same recipe. Round hard and label your units as you go. 1. **State your assumptions.** Daily active users, actions per user per day, size per item, and how long data is kept. Say them out loud and write them down - the interviewer may correct one, and now your whole calculation updates cleanly. 2. **Throughput (QPS).** Average QPS = daily events / 100,000. Peak QPS = average x 2 to 3. Do reads and writes separately. 3. **Storage.** Items per day x size per item x retention period. If bandwidth matters, it is just QPS x payload size. That's all there is. ## Worked example: a URL shortener **Assumptions:** 100 million new links a day, reads outnumber writes 10:1, ~1 KB stored per link, kept for 5 years. **Throughput:** ```text Write QPS = 100,000,000 / 100,000 = 1,000 Peak writes = 1,000 x 3 = ~3,000 Read QPS = 1,000 x 10 = ~10,000 ``` **Storage:** ```text Links in 5 years = 100M x 365 x 5 = ~180 billion Storage = 180 billion x 1 KB = ~180 TB ``` **What it tells you** - and this is the point of doing it: writes are tiny (a single database handles ~1,000/s without blinking), reads dominate so the redirect path must be cached, and ~180 TB will not sit on one disk, so the store needs to be distributed. Three architectural decisions from a minute of arithmetic. When the read path is this skewed, splitting reads from writes with a pattern like [CQRS](/command-query-responsibility-segregation-cqrs) becomes a natural move. ## Worked example: a social feed **Assumptions:** 200 million daily active users, 2 posts each per day, 10% of posts carry a 1 MB image, users open their feed ~20 times a day, kept 5 years. **Throughput:** ```text Write QPS = (200M x 2) / 100,000 = 4,000 peak ~12,000 Read QPS = (200M x 20) / 100,000 = 40,000 (feed loads) ``` Reads are ten times the writes, so this is firmly read-heavy: cache aggressively and precompute feeds rather than building them on every read. **Storage** - media dwarfs text, so estimate media: ```text Media/day = 200M x 2 x 10% x 1 MB = 40 TB per day 5 years = 40 TB x 365 x 5 = ~73 PB ``` Petabytes of media means object storage plus a CDN, with clients uploading directly via something like [presigned URLs](/what-are-presigned-urls) rather than streaming through your servers. The text is a rounding error next to the media - which is itself a useful finding. ## What the numbers decide The reason interviewers ask for estimates is that the estimate *chooses the architecture*: - **Small QPS and small storage** -> a single database is fine. Don't over-build. - **Reads far outnumber writes** -> caching, read replicas, and precomputed views. - **Huge storage, especially media** -> sharding, object storage, and a CDN. - **High write QPS** -> queues and async processing to smooth the load. Five minutes of arithmetic is what separates "I'd add a cache" as a guess from "reads are 40,000/s against 4,000 writes, so we cache and precompute" as a justified decision. ## The habits that keep it easy - **Round aggressively.** 86,400 becomes 100,000; `99,987 / 9.1` becomes `100,000 / 10`. Precision is not the point - you are choosing between "one server" and "a thousand servers," and rounding never changes that answer. - **Label every unit.** "5" is useless; "5 MB" and "5 ms" are decisions. Mixing up KB and MB is how an estimate silently goes wrong by a factor of a thousand. - **Say your assumptions out loud.** They are the inputs; if one is off, the interviewer corrects it and you recompute in seconds. - **Size for the peak, and split reads from writes.** Averages hide the spikes, and systems are lopsided. - **Sanity-check the answer.** Does ~73 PB feel right for a feed's media? Stepping back to ask "is this plausible?" is a senior move and catches arithmetic slips. ## You can now size a system in five minutes You do not need a wall of memorized latency figures. You need one approximation - a day is ~100,000 seconds - a rough sense of data sizes, and the three-step recipe: assumptions, then QPS, then storage. Do that, and the scale numbers hand you the architecture instead of leaving you guessing. Next in this series we put estimation in its place: the full high-level-design framework and how to spend the 60 minutes of the interview, where these calculations are the quick sanity check you run right after sketching the components. The framework here follows the one in Alex Xu's [System Design Interview](https://bytebytego.com); to practice estimates against more problems, the [system design primer](https://github.com/donnemartin/system-design-primer) has a good set.