Back-of-the-Envelope, Revisited

3. Estimate in Ranges, Not Points

Every input to an estimate is uncertain, and a single number hides that. Worse, uncertainty compounds in a way most people underestimate.

Suppose three inputs are each uncertain by a factor of two in either direction, which is normal for user counts, request sizes and growth rates. Multiply them and the product spans a factor of eight above and eight below. The single number sitting in the middle of a sixty-four-fold range looks far more certain than it is.

So carry three numbers rather than one: a low case, a likely case, and a high case. Then look at where the range sits relative to the decision you are making.

• If the whole range falls on one side of the threshold, you are finished. The uncertainty does not matter, and saying so out loud is a strong move.
• If the range straddles the threshold, you have found the one input worth measuring rather than guessing. That is the most valuable output an estimate can produce.

That changes what estimation is for. You are not trying to find the right number. You are trying to find out whether you already know enough to decide, and if not, exactly which measurement would settle it.

4. The Three Estimates That Decide Architecture

Most design-relevant estimates fall into three families, and each has a rough threshold where the design changes shape.

Peak write throughput. Compute writes per second at peak, not average. The question it answers is whether a single primary can hold the write path. Low thousands per second is comfortable for a relational database on good hardware. Tens of thousands is possible with care. Beyond that you are choosing between partitioning the writes, batching them, or accepting a different storage engine. Reads do not force this decision, because reads can be spread across copies and writes mostly cannot.

Working set against memory. The working set is the data actually touched in a typical window, which is almost always far smaller than the total. Compare it to the memory you can afford. If the working set fits, reads are a solved problem. If it is ten times larger, you are designing a cache with a hit rate you must now estimate, and the design has a new failure mode. The interesting case is when the working set is two or three times memory, because that is where the answer depends on access skew.

Fan-out. For each write, how many other things must change? One row is a normal system. A hundred is a background job. A million is an architecture, and probably a different one for the worst case than for the common one. Fan-out is the estimate that most often eliminates an otherwise reasonable design, and it is the one candidates compute least often.

5. Sanity Checks That Catch Real Errors

Arithmetic errors in estimation are usually not small. They are factors of a thousand, caused by a unit slip. Four checks catch nearly all of them, and they take seconds.

• Make the units cancel. Write the units beside the numbers and confirm that what remains is what you claimed to compute. Requests per second times bytes per request gives bytes per second, and if your answer is in bytes, something went wrong.
• Ask whether the answer is a lot. Convert the result into something with a familiar size. Is that one laptop or a thousand racks? Is it one percent of a disk or a hundred of them? A number you cannot picture cannot be checked.
• Compare against a system you know. If your estimate says this product needs more storage than a well-known service with a hundred times the users, the estimate is wrong, not the product.
• Check both ends. Compute the result from the inputs, then take the result and work backwards to one input. A silent factor of a thousand rarely survives being derived twice.

The habit worth building is doing these out loud. An interviewer cannot see you check your work silently, and a colleague cannot either.

6. The Senior Decision: Stop When the Answer Is Decided

Estimation has a natural stopping point, and it is earlier than most people think. You stop when one more digit of precision would not move the decision.

That gives a simple procedure, and it is the whole lesson.

1. Name the decision. "I want to know whether writes fit on one primary."
2. Name the threshold. "One primary is comfortable to roughly ten thousand writes per second."
3. Estimate in a range, rounding hard.
4. Compare the range to the threshold. If it is clearly on one side, decide and move on. If it straddles, name the one input you would measure.

That protects you from the most common failure in a design discussion: spending ten minutes on arithmetic that was never going to change anything. The time was not the real cost. The real cost is that the arithmetic looked like rigor, so nobody asked whether the right question was being answered.

What the interviewer is scoring: the signal is not whether your arithmetic is correct. It is whether you said what the number was for before you computed it. A candidate who announces "I want to know if this fits on one database, and the threshold is around ten thousand writes a second" has shown the entire skill in one sentence. The arithmetic that follows is almost a formality. Expect to be pushed on uncertainty: "how confident are you in that user count?" is an invitation to show that you know which input the answer is sensitive to. The strongest candidates also say when they are finished, which sounds like "the low end of my range is already above the threshold, so I do not need a better number."