What is the back-of-envelope estimation step in a system-design round actually for?
answer
- Not arithmetic for its own sake
- One number that changes a choice
- Say the assumption before the multiplication
- Round hard, then write it on the canvas
- Finish the sentence: therefore X, not Y
basics
~20 sEstimation exists to size the design, not to display arithmetic. In about five minutes you turn the agreed load into one or two rough numbers, write them next to the requirement they came from, and say which design option each one rules in or out.
solid answer
~40 sThe point is that a number should **change a decision**. I state the assumption out loud before any arithmetic, round aggressively, and land on one or two figures - a peak rate, a rough daily volume, a storage growth per month. Then I write each beside the requirement line on the shared canvas that produced it and say what it settles: whether a single instance can plausibly absorb the peak, whether the data will outgrow one machine within a year, whether a synchronous path is even viable. If the arithmetic is right but nothing about my design differs because of it, I wasted five minutes of a 45-minute round. Precision is not the goal; an order of magnitude that moves a choice is.
go deeper
Know that a rough sizing step exists between scoping and drawing, and that its numbers are meant to be approximate. Be ready to state an assumption out loud before doing any multiplication.
Explain the mechanics: assumption first, round aggressively, write the figure beside the requirement it came from, and name the design option it rules in or out. Expect to be asked which estimates are worth the minutes.
Show judgment about which quantities discriminate between the designs you are actually weighing, and skip the rest. Be ready to say how your design changes if the interviewer moves your figure by an order of magnitude.
Own the tradeoff between spending minutes on sizing and spending them on depth. Be prepared to argue when a rough sizing is not worth doing at all, and what you rely on instead to keep the design honest.
## The estimate is an input, not an exhibit Candidates who have read a preparation guide know that a system-design round has an estimation beat, and many of them perform it: they multiply some numbers, announce a result, and then draw the design they were always going to draw. That is the failure mode in miniature. **An estimate that changes nothing is theatre**, and interviewers - typically an engineer from the team you would join, taking notes - read it as such. The beat is worth roughly five minutes of a 45-minute round, and it earns them only if the output feeds the next beat. ### The four moves **1. Say the assumption before the arithmetic.** The number is unfalsifiable without it. *I am assuming a few million sends a day and a peak around three times average* is checkable in a second; *about a hundred per second* is not. The assumption is also the part the interviewer can correct, which is exactly what you want them doing. **2. Round hard.** Take an invented example at a Series C scale-up: 3.2 million notification sends a day is about 37 per second averaged out, so call peak roughly 110 per second. Nobody wants the third significant figure, and reaching for it wastes the beat. If your arithmetic needs a calculator, you have chosen the wrong granularity. **3. Write it on the canvas, beside the line it came from.** The estimate is not a spoken aside. Put *~110/s peak* next to the throughput requirement on the requirements list at the top of the shared design canvas, and *~40 GB/month* next to the retention line. Now the number is available for the rest of the round, and the interviewer can see the chain from requirement to figure to component. **4. Say what it rules in or out.** This is the move that makes the beat count. *At around a hundred a second, a single process can plausibly absorb the peak, so I am not going to shard the front door - I will keep that simple and spend my complexity budget on delivery retries instead.* Or the reverse: *this is large enough that a synchronous send-and-wait path will not hold, so there is a queue in the design and the requirement for it is that line up there.* ### Which estimates are worth doing Only the ones that discriminate between designs you are actually weighing. In practice that is a very short list: - **Peak request rate**, when it decides whether one instance is plausible or whether you need to spread load. - **Data volume over some horizon**, when it decides whether the data fits on one machine or needs partitioning. - **Fan-out or amplification**, when one incoming request causes many outgoing ones and the ratio changes the design shape. Skip anything else. Estimating a figure that leads to the same design either way is time you have taken from the deep dive. ### When the interviewer waves it off Some interviewers say *do not worry about numbers*. Take the offer, but do not lose the reasoning: say the one thing the numbers would have settled - *fine, I will assume this is large enough that a single instance will not hold peak, and design accordingly* - and move on. You get the decision without spending the minutes, and you have shown you know what the beat was for. ### How this connects to the beat before and after Estimation sits between scoping and design precisely because it is the bridge. Scoping produces claims about load; design consumes them. If your requirements list has no load line, you have nothing to estimate from, and doing arithmetic on invented traffic is worse than skipping it. If your design does not reference the estimate, the bridge carried nothing. The cleanest self-check, and the thing to rehearse: after you finish the beat, be able to complete this sentence in one breath - *because of that number, I am doing X rather than Y*. If you cannot, cut the estimate and give the minutes back to the design. ### Common mistakes - **Precision theatre.** Carrying figures to several significant digits, or reaching for exact byte sizes, signals you have missed the purpose. - **Estimating in a vacuum.** Numbers with no stated assumption cannot be corrected or trusted. - **Numbers that never leave your mouth.** If the figure is not on the canvas beside its requirement, it is gone by minute thirty. - **A design fixed before the arithmetic.** If the boxes were already drawn, the estimate is decoration - and this is the same habit as drawing boxes before agreeing requirements, one beat later.
- I do not care about the numbers here - can you skip the estimate?Happily, but let me keep the conclusion. I will assume the load is large enough that a single instance will not hold peak and design for spreading it; if that assumption is wrong, tell me and the shape changes. That way I get the decision the arithmetic would have given me without spending the minutes on it.
- Your peak figure is off by a factor of ten - does your design change?That is the useful question, and I would rather find out now. At ten times that rate the simple single-instance front door stops being plausible, so the entry path gets partitioned and the retry store stops fitting on one machine. If a factor of ten changes nothing in my design, I picked an estimate that was not worth doing.
- Which estimate would you do first if you only had two minutes?Peak request rate, because it is the one that most often decides the overall shape - whether a synchronous path is viable at all. Data volume matters, but it usually pushes a single component's storage choice rather than the structure of the whole design, so it can wait for the deep dive.
saying these in an interview costs you the question
- Computing numbers that leave the design completely unchanged
- Carrying estimates to several significant figures under time pressure
- Multiplying without stating the assumption behind the input
- Keeping the figure spoken only, never written beside its requirement
- Drawing the design first and back-filling arithmetic to justify it