Module 01 · Lesson 03
Back-of-the-envelope estimation
Four numbers, rounded hard, said out loud with the decision attached.
What you will be able to do
- Convert users and actions into requests per second
- Convert record size and write rate into storage per year
- Use rounding constants to do the maths mentally
- Attach a design decision to every estimate you state
- Recognise when an estimate changes the answer and when it does not
What estimation is for
Estimation is not a maths test. It is how you decide which parts of a system deserve complexity. The output of the exercise is not a number — it is a sentence like "we need a cache" or "one database is enough" or "this has to be partitioned by user". If your arithmetic does not change a decision, you have spent minutes for nothing.
Three figures are usually enough
Requests per second, storage over a fixed horizon (a year is honest), and peak bandwidth. Add concurrent connections only if the system is real-time. Everything else is detail you can invent if asked.
The rounding constants
These four constants turn most interview arithmetic into single-digit multiplication. Memorise them and the maths stops being scary.
Seconds in a day
~100,000
Real value 86,400. The rounding error is 15% — irrelevant at this precision.
Seconds in a month
~2.5M
30 days x 100k. Also good for "per 30 days".
Seconds in a year
~30M
But for storage, prefer months x 12: easier to reason about.
Peak multiplier
3-5x average
Consumer products peak in the evening, B2B peaks mid-day.
The method, in four steps
Start from users, not from requests
Even a made-up user count grounds everything that follows: "say 10 million daily users." Write it on the board so the interviewer can correct it early.
Multiply by actions per user per day
One action is one write. Reads get their own multiplier from the read/write ratio. 10M users x 2 posts = 20M writes per day.
Divide by 100,000 to get per-second
20M writes per day / 100k seconds = 200 writes per second. Multiply by the peak factor for the number you design against.
Multiply by record size for storage
200 writes per second x 100k seconds x 0.5 KB x 365 days ≈ 3.6 TB per year. Round the size, round the result.
A full worked example
Prompt: a photo-sharing feed. Ten million daily active users, each posting twice a day and scrolling a feed fifty times. Images average 800 KB after compression. Feeds are read far more than written.
WRITES 10M users x 2 posts = 20M uploads/day 20M / 100k s = 200 uploads/s (average) 200 x 5 (peak) = ~1,000 uploads/s at peak READS 10M users x 50 scrolls = 500M feed reads/day 500M / 100k s = 5,000 feed reads/s average 5,000 x 5 (peak) = ~25,000 reads/s at peak read:write ratio = 25:1 -> reads dominate STORAGE 20M x 800 KB = 16 TB per day 16 TB x 365 = ~5.8 PB per year of raw images plus thumbnails (~15%) = ~6.7 PB per year BANDWIDTH uploads: 1,000/s x 800 KB = 800 MB/s in at peak reads: 25,000/s x 80 KB (thumbnail) = 2 GB/s out at peak
Now the interesting part — what those numbers change:
- 25:1 read to write means the feed read path is the system, so caching and precomputation get the design budget.
- 200 uploads a second of 800 KB is fine for direct-to-object-storage uploads and terrible through an app server, so uploads bypass the API tier.
- 5.8 PB a year means images live in object storage with a CDN, never in the database.
- 25,000 reads a second at peak means the feed response cannot hit the database per request — it gets cached per user or assembled from a fan-out store.
Say the consequence, not the number
Compare "about 5,000 reads per second" with "about 5,000 reads per second, so each request cannot go to the database — we need a cache or a precomputed feed." The second sentence is what scores. The number is only evidence.
Sizes: powers of two
| Power | Exact | Approximate | Use it for |
|---|---|---|---|
| 2^10 | 1,024 | 1 thousand (KB) | A row, a message |
| 2^20 | 1,048,576 | 1 million (MB) | An image, a document |
| 2^30 | 1.07 billion | 1 billion (GB) | A video, a day of logs |
| 2^40 | 1.1 trillion | 1 trillion (TB) | A month of image uploads |
| 2^50 | 1.1 quadrillion | 1 quadrillion (PB) | A year of media at scale |
Treat KB, MB, GB, TB, PB as steps of 1,000 for arithmetic and steps of 1,024 for honesty. The gap never matters in an interview, and pretending it does is worse than rounding.
Two arithmetic shortcuts worth knowing
- Chained division: halving repeatedly is easier than dividing. To get per-second from per-day, divide by 100k — that is two divisions by 10, then by 1,000.
- Per-user, not per-system: work out the cost for one user per day ("20 photo views, 32 KB each"), then multiply by the user count. Multiplying small numbers is more reliable than reasoning about petabytes.
Where estimation goes wrong
Instead
Precise arithmetic ("86,400 seconds, so 231.48 writes per second")
Do this
Round to one significant figure. Precision signals you have missed the point; the architecture does not change between 200/s and 231/s.
Instead
A number with no consequence ("so we have 3.6 TB")
Do this
Attach the decision: "3.6 TB a year, so this fits on one primary with room to spare — no sharding yet."
Instead
Estimating everything
Do this
Estimate the axis that constrains the design. For a chat app that is concurrent connections and fan-out, not storage.
Instead
Ignoring the peak
Do this
Average is for capacity planning; peak is for correctness. A system sized for average falls over exactly when it matters.
Instead
Refusing to commit
Do this
Say the number, state the assumption, move on. "Assuming 10M daily users, 200 writes a second." If the interviewer disagrees, they will say so — that is the point of saying it early.
Q. What if I genuinely do not know the user count?
Say a range and pick a design that survives both ends: "If it is 1M users, one database with a read replica is fine; if it is 100M, we shard by user ID. Let me design for 10M and name where it breaks." Naming the breakpoint is the skill.
Q. How much storage do I assume per record?
Use round defaults and say them: 1 KB for a text row, 5 KB for a short post, 100 KB for a thumbnail, 1 MB for a photo, 50 MB for a minute of video. The interviewer will correct a size assumption faster than they will correct a wrong conclusion.
Worth remembering
- A day is 100,000 seconds, not 86,400, and a month is 2.5 million seconds. That single rounding makes most estimations mental arithmetic.
- Order of magnitude is the product. 3,300/s versus 3,700/s is the same answer; 300/s versus 30,000/s is a different architecture.
- Every number you say out loud should end in "...which means we need X". Ungrounded arithmetic scores nothing.
- Peak is 3 to 5 times average. Design for peak, cost for average.
Checkpoint
Answer all 3 questions to finish the lesson.
1. Roughly how many seconds are in a day, for estimation purposes?
Rounding to 100,000 keeps the arithmetic mental, and the 15% error never changes the architecture. Using the exact figure invites arithmetic you cannot do while talking.
2. A service has 30M writes per day and a peak of 4x average. What should you design the write path for?
30M / 100k = 300 writes per second average. Multiply by the 4x peak factor to get 1,200/s, which is the number the write path must survive.
3. Which sentence is the useful output of an estimation?
The estimate earns its place only when it selects a component. The bare number is trivia; the number plus the decision is engineering.