Back-of-the-Envelope Estimation
Five minutes of arithmetic tells you which box breaks first, before you draw any boxes.
The story
Twenty minutes into a photo-sharing design, the whiteboard is full: Kafka for uploads, a Redis cluster, Postgres sharded sixteen ways, a separate metadata service. It looks like a big-company architecture.
Then the interviewer asks one question: "How many uploads per second is that?"
The candidate doesn't know. So they work it out on the spot. Ten million daily users, one in ten uploads a photo a day: a million uploads a day. A day is about a hundred thousand seconds. About ten uploads per second. Thirty at peak.
A single Postgres primary handles that while mostly idle. Sixteen shards were solving a problem the system doesn't have. The real problem, the one nobody drew, is that ten million people looking at photos pull gigabytes per second out of the system, and nothing on the board was built for that.
Five minutes of arithmetic would have changed the whole design. That's what estimation is for. You're not trying to get the number exactly right. You're finding out which part of the system is under pressure, so you spend the interview designing that part.
The idea: a pipeline from users to bottleneck
Every estimate follows the same chain. Each step takes one multiplication.
The last step is the one people skip. A number on its own means nothing. "17,000 reads per second" only matters once you compare it with what one box can do: too much for one database, easy for a cache, trivial for a CDN.
The numbers worth memorising
You need about fifteen numbers. Round all of them aggressively; you only care about the order of magnitude.
Time and rate
| Fact | Round it to |
|---|---|
| Seconds in a day (86,400) | 10⁵ |
| 1 million per day | ~12 per second |
| 1 billion per day | ~12,000 per second |
| Peak vs average | 2–3× (more for event-driven traffic: ticket sales, match kick-off) |
Size
| Thing | Rough size |
|---|---|
| A UUID / a timestamp | 16 B / 8 B |
| A typical row (a tweet, an order, a message) | 0.5–1 KB |
| A compressed thumbnail | 20–50 KB |
| A phone photo | 1–3 MB |
| A minute of 1080p video | ~50–100 MB |
What one machine can do (planning numbers, not benchmarks)
| Box | Comfortable load |
|---|---|
| App server, simple JSON API | 1,000–5,000 requests/s |
| Postgres / MySQL primary, simple indexed writes | ~5,000–10,000 writes/s |
| Same database, indexed point reads | tens of thousands/s |
| Redis node | ~100,000 ops/s |
| One server's network card | 10 Gbps ≈ 1 GB/s |
Latency, as a ladder. Each rung is roughly 10–1,000× the one above it.
The ladder is why caches exist (memory is about 1,000× faster than SSD) and why a page that makes forty cross-region calls feels broken (Data Locality covers that).
Worked example: the photo app
Inputs: 10M daily users, 1 in 10 uploads a photo a day, each user opens the feed 50 times a day, each feed shows 20 thumbnails.
| Step | Arithmetic | Result |
|---|---|---|
| Uploads per day | 10M × 0.1 | 1M |
| Upload writes/s | 1M ÷ 10⁵, × 3 for peak | ~10 avg, ~30 peak |
| Feed loads/s | 10M × 50 = 500M/day ÷ 10⁵, × 3 | ~5,000 avg, ~15,000 peak |
| Photo storage per year | 1M × 2 MB × 365 × 3 replicas | ~2 PB |
| Metadata per year | 1M × 500 B × 365 | ~180 GB |
| Thumbnail egress at peak | 15,000 × 20 × 30 KB | ~9 GB/s |
Now compare each line with one machine:
The design writes itself: one relational database for metadata, a cache in front of the feed, object storage for the bytes, and a CDN doing most of the work. The sixteen-shard cluster from the story is gone. The CDN it didn't have is now the most important box.
Try it yourself. Predict which resource breaks first, then reveal:
The trade-offs
Where estimation helps
- It stops you over-building. Most interview systems need far fewer machines than candidates draw.
- It points at the real bottleneck. Read-heavy, write-heavy, storage-heavy and bandwidth-heavy systems are four different designs.
- It gives you numbers to justify choices with. "Sharding, because 50,000 writes/s is five primaries' worth" beats "sharding, because scale".
Where it misleads
- Averages hide peaks. A ticketing site averages 100 orders/s and gets 50,000 in the minute sales open. Ask about the shape of the traffic, not just the volume.
- Skew. A million users in total doesn't mean they're spread evenly. One celebrity account can be 1% of all reads on a single key.
- Precision theatre. Spending five minutes on 86,400 vs 100,000 wastes the time estimation was meant to save.
Cheat sheet
| You want | Do this |
|---|---|
| Requests per second | per-day count ÷ 10⁵ |
| Peak | average × 2–3 (ask if traffic is spiky) |
| Storage | items/day × size × 365 × years × replicas |
| Bandwidth | peak requests/s × response size |
| Is it one machine? | compare with: app 1–5k rps · DB primary ~5–10k writes/s · Redis ~100k ops/s · NIC ~1 GB/s |
| Read:write ratio | if it's over 10:1, caching and replicas dominate the design |
| Time to spend | 3–5 minutes, right after requirements, before boxes |
Say it in the interview
"Before I draw anything: 10M daily users at one upload each per ten users is about 10 writes a second, 30 at peak, so one primary is fine. Reads are 15,000 a second and egress is around 9 GB a second, so the design is really about caching and a CDN. I'll spend most of our time there."
Go deeper
- SD 2 · Chapter 1 — The Speed of Physics: where the latency ladder comes from.
- SD 2 · Chapter 19 — The System Design Framework: where estimation sits in a full interview answer.