Back-of-envelope estimation
Rough maths, done out loud, that tells you which problem you have.
What problem does back-of-envelope maths solve?
Every design has one hard part and several easy parts. They look the same until you do the maths. Without numbers you spend your best ten minutes on the easy part.
The point is not the number. The point is the sentence the number lets you say: "so the hard part here is ___". If your estimate did not change what you were about to build, you did the maths wrong or you ignored the answer.
What back-of-envelope maths costs you
Every concept in here states a cost. A technique with no price is a technique you have not understood yet — and naming the cost out loud is most of what separates a senior answer from a junior one.
When to reach for back-of-envelope maths, and when not to
Use it when
- Right after requirements, before you draw a single box.
- When you feel yourself about to say "we will shard it". Check first whether you need to.
- When two designs are being argued about in circles. Numbers usually settle it.
Do not, when
- The interviewer says "assume it is huge, skip the maths". Take the offer. Say the one conclusion you would have drawn, then move on.
- The number changes nothing, like the exact bytes of logs per month. Do not do maths for its own sake.
How back-of-envelope maths actually works
So the hard part is reads. Write sharding, batched inserts and a write-optimised store would all have been ten wasted minutes. One cache and a read replica solve the problem you have.
The method has five steps. First, users: pick a number of daily active users, and say clearly that you picked it. Second, actions per user per day. Multiply those, then divide by 100,000. A day has 86,400 seconds, and 100,000 is close enough and much easier to divide by. That gives you the average per second.
Third, peak traffic. Traffic is never flat. Multiply the average by 2 to 10, depending on the product. A work tool spikes hard on weekday mornings. A worldwide chat app barely spikes at all. Say which one you assumed, and why.
Fourth, storage: bytes per record, times records per day, times days you keep them. Fifth, and this is the step people skip: read your answer back and finish the sentence "so the hard part here is ___."
Useful anchors. One million seconds is about 11 days. A day has 86,400 seconds, call it 100,000. A kilobyte of text is a paragraph. A megabyte is a small photo. A terabyte fits on one disk you can hold in your hand, so "a few terabytes" is not a scale problem. That is a normal database.
- Doing the maths and then designing as if you had not. The estimate has to change a decision, or it was decoration.
- Fake precision. "1,847 requests per second" from made-up assumptions is worse than "roughly two thousand".
- Forgetting peak traffic, then being caught out by the sale-day question later.
The back-of-envelope maths follow-up an interviewer will ask
You estimated 500 GB of data. The interviewer asks: "so how many machines?"
Probably one, and that is the interesting part. 500 GB fits easily on a single normal server. So the size of the data is not what forces you to split it up. Something else does: a request rate one machine cannot serve, an uptime promise one machine cannot keep, or a blast radius you cannot accept. Say which one applies. If none of them do, say that: "at this size I would run one primary with a replica for failover, and I would look again when we are 20 times bigger." Choosing not to split, out loud, with a reason, scores better than splitting out of habit.
Your turn
A service has 10 million daily active users, each doing 20 actions a day. What is the rough average requests per second, and what is a reasonable peak?
Learn it from the source
This page gets you interview-ready. These take you to where the idea is actually specified or measured — read them when you want the real depth.
- Back-of-the-envelope calculation ↗The general technique, outside software. Useful for seeing why the method works at all.
- MDN — Understanding latency ↗The browser-side numbers you will be estimating against.