Start here: 'it depends on the scale' is not an answer#
TL;DRthe 30-second version
- Estimation is multiplying a few stated assumptions until you get a number that decides a design choice. It is not forecasting, and it is not meant to be accurate.
- You are aiming for the right power of ten. Being off by two times is fine. Being off by a thousand times means you picked the wrong architecture.
- The chain is always the same: users, then actions per user, then per second, then peak, then bytes.
- Round to one significant figure at every step. It keeps the arithmetic mental, and the error it adds is far smaller than the error already in your assumptions.
- Say every assumption out loud before you multiply. A wrong assumption an interviewer corrects in one sentence is cheap; a wrong assumption they discover ten minutes later is not.
Imagine you are asked to design a photo-sharing app. You start drawing boxes, and the interviewer stops you: how much traffic is this? The tempting answer is that it depends on the scale. That is true, and it is worth nothing, because you are the one who gets to decide the scale. Nobody is going to hand you a traffic figure. The interviewer is checking whether you can produce one and then defend it.
So say you guess instead. You announce that the app does a million requests a second, because a million sounds like a big popular app. Now watch what that guess costs you. A million requests a second is about ten times what Google Search fields across the entire public internet. It implies thousands of servers, a global delivery network, and a team of hundreds. For the next twenty minutes you will be defending an architecture that the product never needed, and every follow-up question will make the mismatch worse.
Now do it the other way. You say: assume ten million people use this every day, and each of them uploads one photo and looks at fifty. That is ten million uploads a day, which is a hundred and fifteen a second, call it a hundred. And five hundred million views a day, which is about six thousand a second. Those two numbers took fifteen seconds to produce, and they immediately tell you the shape of the system: the write path is small enough for one database, and the read path is sixty times bigger and belongs behind a cache. You have not been more accurate than the guess. You have been checkable, which is the thing being scored.
The chain: users to bytes, one multiply at a time#
Every back-of-the-envelope estimate is the same short chain, and each link is one multiplication or one division. You start with a count of people, turn it into a count of actions, turn that into a rate, adjust the rate for the fact that traffic is not flat, and then turn the rate into bytes. Nothing in the chain is clever. What makes it work is that every link is visible, so anyone listening can stop you at the exact step they disagree with.
- State the daily active users. Pick a round number and say where it came from: a comparable product, a market size, or the interviewer's own hint.
- State the actions per user per day, split by kind. Posts and reads are different numbers, and their ratio is the most important thing you will produce.
- Multiply to get actions per day, then divide by 86,400 to get the average second.
- Multiply by a peak factor of two to five, because traffic clusters into a busy hour. Quote the peak number, since that is what the system has to survive.
- Multiply the rates by the size of one item to get bytes: bytes a second on the wire, bytes a day on disk, bytes of it hot enough to keep in memory.
- Round every result to one significant figure and say it in words. Twenty thousand a second, half a petabyte a year, a hundred gigabytes of cache.
That last step is the one people skip, and it is the one that makes the rest possible. Rounding to one significant figure means keeping the leading digit and turning everything after it into zeroes. Seventeen thousand three hundred and sixty-one becomes twenty thousand. Five hundred and forty-seven terabytes becomes five hundred. You can multiply numbers like that in your head while talking, which is the whole point: the arithmetic has to happen at conversation speed or it stops being a conversation.
It feels wrong to throw away that much precision, so it is worth being clear about why it is safe. Your assumptions are already guesses. You do not know whether users post twice a day or three times, and that alone is a fifty per cent error. Rounding to one significant figure adds at most another fifty per cent on top of an input that was never better than that. The rounding is not what makes the answer approximate. The assumption was.
Go deeperDoes the error pile up over a five-step chain?
Less than you would fear. Rounding to one significant figure keeps you within about fifty per cent of the true value in the worst case, and usually much closer. Errors like that do not simply add up, because some round up and some round down, so they partly cancel. Even if you assume the worst and every step rounds the same way, five steps of at-most-fifty-per-cent error land you within about a factor of seven of the truth.
A factor of seven sounds terrible until you remember what the number is for. You are choosing between one machine, a rack, and a data centre. Those options are separated by factors of a hundred and a thousand, not by factors of seven. The estimate only has to be good enough to pick the right option, and one significant figure clears that bar with room to spare.
There is one case where the compounding does bite: when you multiply several independent guesses that you have deliberately made generous. Four assumptions each rounded up by two times is a sixteen-times overestimate, and that can move you a whole architecture. The fix is to round to the nearest value rather than always upward, and to say out loud which single assumption the answer is most sensitive to.
The constants you should know cold#
There are about a dozen numbers worth having memorised. They are not trivia. Each one is a step you would otherwise have to stop and work out, and stopping is what turns a fluent estimate into an awkward silence.
Start with the powers of ten, because every estimate ends up expressed in them. The trick that makes the arithmetic mental is that two to the power of ten is 1,024, which is close enough to a thousand that you can treat memory and storage prefixes as powers of a thousand and be within two and a half per cent per step.
| Prefix | Value | Rough feel | Typical use |
|---|---|---|---|
| thousand (K) | 10^3 | a small town | requests per second on a busy service |
| million (M) | 10^6 | a large city | daily active users of a real product |
| billion (G) | 10^9 | the internet's user base | rows in a mature table |
| trillion (T) | 10^12 | a bank's balance sheet | events per year at large scale |
| quadrillion (P) | 10^15 | a petabyte in bytes | a very large company's storage |
Next, the seconds in a day: 86,400. It is the single most-used constant in these estimates, because every product figure arrives per day and every capacity figure is needed per second. Two useful facts about it. It is close to a hundred thousand, so dividing by a hundred thousand gets you within about fifteen per cent, which is well inside your error bars. And it is close to ninety thousand if you want to be a little tighter without losing the mental arithmetic.
Then the sizes of things. You will constantly need to turn a count of items into a count of bytes, and the estimates below are the ones that come up most.
| Thing | Rough size | Why |
|---|---|---|
| One character of plain text | 1 byte | ASCII; assume 2 to 4 bytes if the text is international |
| A short message or post row | 300 bytes to 1 KB | the text plus identifiers, timestamps, counters, index entries |
| A URL or short link row | 200 to 500 bytes | the original URL dominates; the short code is nothing |
| A compressed photo | 200 KB to 2 MB | phone cameras produce a few megabytes before resizing |
| One hour of HD video | about 2 GB | 5 Mbps for an hour, and 5 Mbps is 625 KB per second |
| A UUID or hash key | 16 to 32 bytes | small, but multiplied by every row and every index |
PredictA messaging app has 200 million daily active users who each send 40 messages a day. Messages average 300 stored bytes and you keep three replicas. Roughly how much new storage does a year need?
Hint: Messages a day, then bytes a day, then bytes a year, then replicas. Do not multiply by the group size.
Start with messages a day: 200 million times 40 is 8 billion. Multiply by 300 bytes and you get 2.4 trillion bytes a day, which is 2.4 TB a day. Multiply by 365 and you are at roughly 880 TB a year for one copy. Three replicas takes it to about 2.6 PB, which rounds to 3 PB a year. The number to say out loud is 'about three petabytes a year'. Two things are worth noticing. First, you stored each message once, not once per recipient — if every group member got their own copy of the body, that figure would multiply by the average group size, which is why real systems store the message once and give each inbox a pointer. Second, a petabyte-a-year growth rate is the number that forces a tiering plan: recent messages on fast storage, older ones moved to something cheaper, because keeping ten years hot means thirty petabytes.
Two multipliers finish the toolkit. The first is the peak factor. Traffic is never spread evenly across a day, because people are asleep for a third of it and busy for another third. The busy hour typically runs two to five times the daily average, so multiply your average rate by three unless you know better. Systems are sized for the peak, so the peak is the number you quote.
The second is the read-to-write ratio: how many reads arrive for every write. It is the single most load-bearing number in most designs. A social feed sits somewhere between ten and a hundred reads per write, and that ratio is the entire justification for putting a cache in front of it. A logging or metrics pipeline can be the other way round, mostly writes with rare reads, and there a cache buys you nothing and the write path is where the money goes. Derive the ratio from the two per-user figures rather than asserting it, because the derivation is what makes it credible.
One more thing worth memorising, because it shows up in every cache estimate: the 80/20 rule. Roughly eighty per cent of the traffic lands on twenty per cent of the data. That fifth is the working set, and it is what has to fit in memory. It is why a service with twenty terabytes on disk can still be served from ten gigabytes of RAM, and it is the difference between a cache tier you can afford and one you cannot.
What accuracy costs, and how much of it you need#
Estimation has one real trade: time against precision. Every extra digit you chase costs seconds you do not have, and in an interview you have about two minutes for the whole exercise before you become the person doing sums instead of the person designing a system.
- More precision costs time and gains almost nothing. The answer is already limited by assumptions you invented, so a second significant figure just adds confidence you have not earned.
- Too little arithmetic costs credibility. Saying 'high scale' without a number leaves every later decision unjustified, and the interviewer has no way to check your reasoning.
- Overestimating over-builds. If your numbers come out ten times too big you will design sharding, multi-region replication, and a delivery network the product never needed, and you will spend the rest of the interview defending complexity.
- Underestimating hides the interesting problem. If the numbers come out ten times too small, the design looks easy and never reaches the bottleneck the question was built around, which is usually the whole point of the problem.
- Unstated assumptions cost the most. A number the interviewer cannot trace is a number they cannot correct, so any error in it silently poisons everything downstream.
There is also a judgement call about which numbers to bother with. Not every problem needs all five. A rate limiter is about request rates and almost nothing else, so storage and bandwidth are a sentence each. A video service is about bandwidth, and its request rate is nearly irrelevant. Work out the numbers that decide something in this design, say why the others do not matter here, and move on. Deriving a figure that changes no decision is a way of looking busy.
The last trade is between the number and the sentence after it. A candidate who produces five correct figures and no consequences has done arithmetic, not design. A candidate who produces three figures and says what each one forces — this rate needs a cache, this working set fits in one machine's memory, this egress needs a delivery network — has done the thing being scored. If you are short on time, cut a number rather than the sentence that follows it.
Four systems, four different numbers that dominate#
The chain is always the same, but which link ends up mattering changes completely from system to system. This is what makes estimation worth practising on more than one problem: the skill is not the multiplication, it is noticing which number is about to decide the architecture. The four systems below are the four scenarios in the trainer.
| System | What dominates | The number that decides it | What it forces |
|---|---|---|---|
| Social timeline | The read-to-write ratio | about 300,000 reads a second at peak, against 20,000 writes | A cache tier sized before the database; writes partitioned by user |
| URL shortener | Request rate, not data size | about 20,000 redirects a second against only 20 TB of rows | Every redirect must be one cache hit; the store itself is small |
| Group chat | Fan-out: one send becomes many deliveries | 300,000 sends a second becoming 3 million deliveries | A separate delivery tier; store the message once and point at it |
| Video streaming | Egress bandwidth | about 4 TB a second leaving at peak, against a 1 PB catalogue | A delivery network at the edge; storage is the cheap part |
Read down the last column and the pattern is clear. Each system has one number that is dramatically larger than the others, and that number is what the design is really about. The failure mode is producing all five figures for every problem and treating them as equally interesting, which buries the one that mattered. Work the chain, then point at the outlier and say why it is the outlier.
The video case is worth dwelling on because it breaks the usual habit. A video request arrives once and then consumes capacity for forty-five minutes, so requests per second is the wrong unit entirely. What you size is concurrency: how many streams are in flight at the same time. That comes from Little's Law, which says the number of things in flight equals the arrival rate multiplied by how long each one stays. Say a hundred million viewers each start a couple of streams a day: that's a couple hundred million starts, about twenty-three hundred a second. Twenty-three hundred starts a second times twenty-seven hundred seconds of watching is about six million concurrent streams, and six million streams at five megabits each is the roughly four terabytes a second the table quotes.
Real published numbers to anchor against
Estimates are more convincing when they land near figures that real companies have published. These are the public anchors worth carrying, and each one is a sanity check: if your estimate for a comparable product comes out a hundred times larger than the real thing, an assumption is wrong.
| System | Published figure | What it anchors |
|---|---|---|
| Twitter (2013) | about 500 million tweets a day, roughly 5,700 a second on average | Write rates for a very large social product |
| Twitter (2013 record) | 143,199 tweets a second at a one-off spike | How extreme a peak factor can get on a viral event |
| Netflix Open Connect | video served from thousands of edge appliances inside internet providers | Why streaming is a delivery-network problem |
| Netflix bitrates | 5 Mbps recommended for HD, 15 Mbps for 4K | Bytes per second per stream |
| over two billion users | The upper end of messaging scale | |
| Datacentre round trip | about 0.5 ms; a cross-continent round trip about 150 ms | Why one extra region costs real latency |
The Twitter pair is the most instructive. The average was around six thousand tweets a second, and a single television event pushed it past a hundred and forty thousand — more than twenty times the average. That is far above the peak factor of three you would use by default, and it is the honest answer to 'what if it spikes': you do not size for the record, you size for the ordinary busy hour and then add a way to shed or queue load when something unusual happens. That is what rate limiting and backpressure are for.
The latency figures are the other anchor worth keeping. They tell you what a design costs before you have written any code: a call to a service in the same datacentre is half a millisecond, a call across an ocean is a hundred and fifty. If your design makes ten sequential cross-region calls, it cannot meet a one-second target, and you can say that from the numbers alone.
Pitfalls and gotchas
How accurate does the answer actually have to be?
Within a factor of ten is a good interview answer, and within a factor of two is indistinguishable from correct. What matters is the power of ten, because that is what changes the design. If you say twenty thousand requests a second and the truth is forty thousand, no decision moves. If you say twenty thousand and the truth is twenty million, every decision moves.
I keep forgetting to apply the peak factor. Does it matter?
Yes, and it is the single most common miss. Using the daily average sizes a system that falls over every evening. Traffic clusters into a busy hour that typically runs two to five times the average, so quote the peak rate and say which factor you used. If you forget, your machine count is roughly three times too small.
Should I use 1,024 or 1,000 for a kilobyte?
Use 1,000. The two differ by 2.4 per cent per step, and by the time you reach terabytes the gap is about ten per cent, which is far inside the error already in your assumptions. Powers of a thousand let you do the arithmetic in your head, and that speed is worth more than the accuracy you gave up. Say that you are rounding, and nobody will mind.
Do I multiply storage by the replication factor?
Yes, and people forget. Three copies means three times the disk, and that is before backups and before the indexes that make the data findable. A useful habit: quote the raw figure first, then say 'times three for replication' as a separate step, so the interviewer sees both numbers.
Should I estimate storage per day, per year, or forever?
Per year is the useful unit, because it is what a capacity plan is written in and it is easy to scale mentally. Quote the yearly figure, then say what five or ten years looks like, because that is the number that decides whether you need a tiering plan. A service adding half a petabyte a year is fine today and needs a plan for cold storage well before year five.
The interviewer gave me a number that contradicts my assumption. What now?
Take theirs, say you are taking theirs, and re-run the affected link. That is a good moment, not a bad one: it is why you stated the assumption separately from the arithmetic. Only the numbers downstream of that assumption change, and because each link was one multiplication you can usually redo them out loud in a few seconds.
QuizA candidate estimates 50,000 writes a second for a photo app and immediately designs sharding, a message queue, and multi-region replication. The interviewer asks where 50,000 came from and the candidate says it felt right for a big app. What is the actual problem?
- The number is too high; a photo app cannot reach 50,000 writes a second.
- The number was asserted rather than derived, so nobody can check it and the entire architecture rests on an unverifiable guess.
- They should have estimated storage before estimating write rate.
- Sharding is never justified at 50,000 writes a second.
Show answer
The number was asserted rather than derived, so nobody can check it and the entire architecture rests on an unverifiable guess. — The figure itself might even be right — plenty of photo apps are that big. The problem is that it arrived with no chain behind it, so there is nothing to check and nothing to correct. Had the candidate said 'assume 100 million daily users each uploading one photo, which is 1,150 a second average and call it 3,500 at peak', the interviewer could have moved a single assumption and everything downstream would follow. Instead the whole design now rests on a number that appeared from nowhere, and every later choice inherits that weakness. Note also what the unchecked figure bought: a peak write rate roughly fifteen times higher than the derivation gives, and therefore an architecture far heavier than the product needs.
In an interview
Estimation happens early, right after the requirements and before you draw anything. It should take about two minutes, and the way you talk through it matters as much as the arithmetic. The goal is to be interruptible: at every step the interviewer should be able to stop you, change one input, and watch you carry on.
- Say the assumptions first, as a short list, before any multiplication. 'I will assume ten million daily active users, one upload each, fifty views each.' Pause there and let them correct you.
- Do the arithmetic out loud, one link at a time, rounding as you go. 'Ten million uploads a day, divided by about a hundred thousand seconds, is a hundred a second. Times three for peak, so three hundred.'
- Quote the peak, not the average, and say which factor you used. The system has to survive the busy hour, so that is the number the design is built against.
- Follow every number with what it forces. A rate that needs a cache, a working set that fits in one machine, an egress figure that needs a delivery network. The consequence is what is being scored.
- Name the number the answer is most sensitive to. Usually it is the read-to-write ratio or the peak factor, and saying so shows you know where the uncertainty actually lives.
- Time-box it. Two minutes, five numbers at most, then move on to the API and the data model. If you are still doing sums after three minutes you have lost the room.
One habit is worth building deliberately: keep the assumptions written somewhere visible, separate from the results. On a whiteboard that is a short column in the corner. It makes the correction cheap, and it means that when the interviewer says to scale it ten times, you change one line and re-run the chain instead of starting over.
PredictHalfway through, the interviewer says: 'now make it ten times bigger.' What actually changes, and what does not?
Hint: Rates scale with the user count. Ratios do not. Which thresholds does the scaling cross?
Every rate and every byte figure multiplies by ten, and you can say so immediately because each one was a chain of multiplications off the user count: ten times the users means ten times the writes, ten times the reads, ten times the storage and the bandwidth. What does not change is the read-to-write ratio, because both sides scaled together, and ratios are what most design decisions actually turn on. So the shape of the design is unchanged and the thresholds you crossed are what moved. The strong answer names the specific crossings: a write rate that fitted on one database now needs partitioning; a cache working set that fitted in one machine's memory now needs a sharded cache tier; an egress figure that a handful of servers could push now needs a delivery network. Then add the thing that does not scale linearly, because it is the part most candidates miss: fan-out. If the average group or follower count also grows with the product, deliveries grow faster than sends, and the delivery tier grows faster than everything else.
References
- Twitter Engineering — New Tweets per second record, and how — The source of the 5,700 average and 143,199 peak tweets per second figures, plus what the spike forced them to build.
- Netflix Open Connect — How Netflix delivers video from appliances inside internet providers — the practical answer to a terabytes-per-second egress estimate.
- Netflix — Internet connection speed recommendations — The published bitrates (5 Mbps for HD, 15 Mbps for 4K) behind the bytes-per-stream assumption.
- Latency numbers every programmer should know (interactive) — Jeff Dean's latency table, scaled by year — cache, memory, disk and network round trips in one place.
- WhatsApp — Two billion users — The published user count that anchors any messaging-scale estimate.
- Google SRE Book — Software Engineering in SRE (capacity planning) — How capacity forecasts are actually produced and used in production, once the envelope is no longer enough.
- System Design Interview, Vol. 1 (Alex Xu) — The back-of-the-envelope chapter: powers of two, availability tables, and the QPS-from-DAU drill in interview form.
Ready to try it?
The simulator is a real, deterministic implementation — pick a scenario and step through it, scrubbing the timeline forward and backward through every change.