Back-of-the-envelope estimation is the quick math you do in a system design interview to size a system: how many queries per second, how much storage, how much bandwidth, how many servers. You are not trying to be exact. You are trying to be right within an order of magnitude, fast, so your design choices (cache or no cache, one database or sharded, sync or async) rest on numbers instead of vibes. The whole thing usually takes three to five minutes near the start of the interview, and interviewers use it to check whether you reason quantitatively before committing to an architecture.
Most candidates get this wrong in one of two directions. They either skip the math entirely and hand-wave ("we'll add a cache"), or they burn ten minutes computing storage to three significant figures that nobody asked for. The goal is a small number of load-bearing estimates, done out loud, that actually change your design.
The numbers worth memorizing
You cannot estimate fast if you are deriving constants on the spot. Memorize three small tables and you are 90% of the way there.
Powers of two. Storage and memory are quoted in bytes, so map the exponents to plain-English magnitudes:
| Power | Approx value | Name |
|---|---|---|
| 2^10 | ~1 thousand | 1 KB |
| 2^20 | ~1 million | 1 MB |
| 2^30 | ~1 billion | 1 GB |
| 2^40 | ~1 trillion | 1 TB |
| 2^50 | ~1 quadrillion | 1 PB |
Time. A day has 86,400 seconds. Round it to 100,000 (10^5) for speed. A month is roughly 2.5 million seconds. This one shortcut turns "1 billion requests per day" into "10,000 QPS" in one step.
Latency. The classic "latency numbers every programmer should know" set is the reference here. The orders of magnitude that matter in an interview: an L1 cache reference is about 0.5 ns, a main memory reference about 100 ns, reading 1 MB sequentially from memory about 250 microseconds, a round trip inside the same datacenter about 500 microseconds, reading 1 MB from SSD on the order of 1 ms, a disk seek about 10 ms, and a packet round trip between California and the Netherlands about 150 ms. The single takeaway: memory is roughly a hundred times faster than SSD, SSD is roughly ten times faster than spinning disk, and a cross-continent network call dwarfs all of them.
Availability. Know what the nines cost you in downtime: 99.9% is about 8.8 hours of downtime per year, 99.99% is about 53 minutes, and 99.999% is about 5 minutes. When someone says "five nines," that is a hard SLA, not a slogan.
A repeatable method
Do it in the same order every time so you never freeze:
- State assumptions out loud. Daily active users, requests per user per day, average payload size. Pick round numbers and say them so the interviewer can correct you early.
- Derive QPS. Total daily requests divided by ~100,000 seconds gives average QPS. Multiply average by 2x to 3x for peak.
- Split reads vs writes. Most consumer systems are read-heavy, often 100:1 or more. This ratio decides your caching and replication story.
- Size storage. Writes per day times payload size times retention period. Add metadata and replication factor.
- Size bandwidth. QPS times payload size for both ingress and egress.
- Sanity-check. Does the result fit on one machine, one rack, or a fleet? That answer is the point.
Round aggressively at every step. Carrying "86,400" instead of "100,000" through five multiplications wastes time and buys no accuracy.
A worked example: a URL shortener
Assume 100 million new URLs created per day, read-heavy at 100:1.
- Write QPS: 100M / 100,000 s ≈ 1,000 writes/sec average, call it ~2,000 at peak.
- Read QPS: 100:1 gives ~100,000 reads/sec average, ~200,000 at peak. That number alone tells you the read path must be cache-first, not database-first.
- Storage: Say 500 bytes per record (URL, short code, metadata). 100M/day times 500 bytes ≈ 50 GB/day, ≈ 18 TB/year. Over five years with replication, low tens of terabytes. That fits comfortably on a sharded database; you do not need anything exotic.
- Cache sizing: Apply the 80/20 rule. If 20% of URLs generate most reads, caching the hot 20% of a day's reads is a few gigabytes of RAM, trivially affordable. That is the decision the estimate exists to justify.
Notice we made exactly one architectural call per number: cache-first reads, sharded storage, hot-set cache. Anything more precise would not have changed those calls.
Common mistakes we see in mock interviews
We run these sessions all day, and the failure patterns are consistent.
- Precision theater. Computing 86,400 x 1,024 x 730 by hand while the interviewer waits. Round to 10^5, 10^3, 10^3 and move on.
- No peak factor. Designing for average QPS, then getting asked "what happens at peak?" and having no headroom. Always state a peak multiplier.
- Forgetting the read/write ratio. It is the single most design-relevant number for consumer systems, and it is the one people skip.
- Estimating things that do not matter. If storage is obviously going to be tens of terabytes either way, do not spend three minutes on it. Estimate the number that flips a decision.
- Silent math. Doing the arithmetic in your head and only stating the answer. Interviewers score the reasoning, not the result, so narrate it.
If your mental arithmetic is shaky under pressure, that is a trainable skill on its own. The same fluency shows up in coding rounds, where you reason about input bounds and complexity, and firms with a quantitative bent lean on it heavily. You can drill the underlying arithmetic and estimation reflexes with math-focused practice, then rehearse the full design flow in a timed mock interview.
Where estimation meets the coding round
At quant-leaning shops like SIG, the estimation reflex is not confined to system design. It carries into how you talk about your code. When you pick up a problem like "Text Justification" or "Spiral Matrix," the interviewer wants to hear you bound the work: how many passes over the input, how much extra memory. Saying "this is one pass, O(n) time, O(1) extra space because I rotate in place" on "Rotate Image" is the same muscle as sizing a fleet, just at smaller scale. Estimating before you build, whether it is petabytes of storage or the number of comparisons in "Minimum Absolute Difference Between Elements With Constraint," is the habit both rounds are testing. Treat back-of-the-envelope math as a general-purpose interview skill, not a system-design-only ritual.
FAQ
How accurate does back-of-the-envelope estimation need to be?
Within an order of magnitude. If the real answer is 40,000 QPS and you say 100,000, that is fine because both point to the same design. Interviewers reward fast, well-reasoned approximations over slow, exact arithmetic, so round aggressively and keep talking.
What is the fastest way to convert requests per day to QPS?
Divide by 100,000. A day is 86,400 seconds, and rounding up to 10^5 keeps the mental math clean while staying accurate enough. So one billion requests per day is about 10,000 QPS average, then apply a 2x to 3x peak factor.
Do I need to memorize the latency numbers exactly?
No, memorize the orders of magnitude and the ratios. Knowing that memory is roughly 100x faster than SSD, SSD roughly 10x faster than disk, and a cross-continent round trip is around 150 ms is enough to justify a caching or replication decision. Nobody expects exact nanosecond figures.
When should I do the estimation during the interview?
Right after you clarify requirements and before you draw the architecture. The numbers should drive your design choices (whether to cache, shard, or use async processing), so doing them first means your diagram is grounded rather than decorative.