0% completed
What Is Back-of-the-Envelope Estimation
On This Page
What the numbers are for
The three rules
How accurate does it have to be
Where it belongs in the interview
Someone asks you to design a system that serves a hundred million people. Before you can choose a database, or decide whether you need a cache, you need to know roughly how much data arrives every second and how much of it you have to keep.
Back-of-the-envelope estimation is a rough calculation, done with round numbers, that tells you the approximate size of the system you are about to design. The name comes from the idea that the whole calculation is short enough to fit on the back of an envelope.
It is not a forecast and it is not a capacity plan. It is a sanity check performed in about five minutes.
What the numbers are for
To find out whether the design is even possible. If the arithmetic says the system needs to write 50 gigabytes per second to a single database, then no amount of clever schema design will save it, and the shape of the answer has to change.
To size the parts. The same arithmetic tells you whether the working set fits in memory, whether one machine is enough, and whether the read traffic is large enough to need a cache in front of the database. These are the decisions the rest of the design hangs on.
To show how you think. In an interview the number itself is rarely the point. The interviewer is watching whether you state your assumptions, whether you notice when a result is absurd, and whether you can get to the right order of magnitude without a calculator.
The three rules
Round aggressively. Use 100,000 seconds in a day instead of 86,400. Use 1 million instead of 1.2 million. The error introduced by rounding is small compared with the error already sitting in your assumptions, and round numbers can be multiplied in your head.
Do one number at a time. Requests per second, then storage, then bandwidth. Each one is a single multiplication or division. Trying to hold the whole calculation at once is where mistakes come from.
Say the assumption out loud before you use it. "I will assume 10 percent of users post each day" is a statement the interviewer can correct. If they say "make it 50 percent", you change one number and the rest follows. An assumption you never stated is one nobody can correct.
How accurate does it have to be
Close enough to make the decision, and no closer.
If the answer is 12,000 requests per second, then 10,000 is the same answer. Both tell you that one server will not do and that you need a load balancer in front of a group of them. Being within a factor of two is comfortable. Being within a factor of ten is usually still useful.
Being wrong by a factor of a thousand is not, and that is the mistake worth guarding against. It almost always comes from a unit slip: seconds confused with days, bits confused with bytes, megabytes confused with gigabytes. The habit that prevents it is writing the unit next to every number as you go.
Where it belongs in the interview
Estimation has a natural place in the conversation, and it is not the beginning.
First clarify what the system has to do and roughly how many people use it. Then estimate. Then draw the high-level design, using the numbers you just produced to justify the components you put on the board.
Doing it before the requirements are clear means estimating the wrong system. Doing it after the design is drawn means the design was chosen without evidence, and it is uncomfortable to discover halfway through the deep dive that the storage does not fit.
💡 Say what each number changes as you calculate it. "That is 10,000 reads per second against 100 writes, so this is read heavy and a cache is going to earn its place." A number with no consequence attached looks like arithmetic. A number that changes the design looks like engineering.
Key takeaway: Back-of-the-envelope estimation is a rough calculation with round numbers that tells you the approximate size of a system before you design it. It exists to test whether a design is feasible, to size its components, and to show your reasoning. Round aggressively, compute one number at a time, and state every assumption out loud. Being within a factor of two or ten is fine, while unit slips that put you off by a thousand are not. It belongs after the requirements are clear and before the high-level design is drawn.
The next lesson, Numbers You Should Know, covers the handful of facts these calculations are built from.
On This Page
What the numbers are for
The three rules
How accurate does it have to be
Where it belongs in the interview