Chapter 2 · System Design Fundamentals
Back-of-the-Envelope Estimation
Rough maths you can do on the back of a napkin, for traffic, speed, storage, and network usage. In under a minute it tells you whether a design is even possible — and which part of it is going to be the real problem.
▶ Open the companion slidesAn estimate is not a prediction. It is a sanity check. It tells you whether you need one server or a thousand, which part of the system will cost the most, and whether the design is quietly assuming something that can't happen. The whole skill is one move done over and over: break a vague question into a chain of small numbers you can defend, multiply them together, and round generously at every step.
Alex Xu, System Design Interview (Vol. 1), Chapter 2; the latency
ladder traces back to Jeff Dean's "Numbers Everyone Should Know." Companion deck:
slides — jump to any slide with the
Slide N chips.
Go deeper: the
interactive
"Latency Numbers Every Programmer Should Know" — drag the year slider and watch the
ladder shift.
Why estimate at all Slide 2
The same ten minutes of maths pays off in four different situations. And in an interview, the final number matters far less than whether you can get to one calmly.
In interviews
It shows you can take a vague question and split it into users, requests, data size, and copies — then talk your way to a total you can defend.
In production
It stops you buying far more servers than you need, or far fewer. It also shows you which part of the system will dominate the bill.
In planning
If a rough sketch already needs 80 PB of memory, the design is wrong. Much better to find that out in a meeting than three months into building it.
In conversation
Numbers settle arguments. "It feels slow" turns into "the slowest 1% of requests take 240 ms and we promised 80 ms" — and now the team knows what to do.
Powers of two Slide 3
Learn these once and storage maths becomes something you can do in your head. For rough work, just treat each binary step as the nearest round decimal number. Even after multiplying three of them together, you're only off by a few percent.
1 KB is 1,000 bytes. 1 KiB is 1,024 bytes — about 2.4% more. That gap widens as the units get bigger, reaching roughly 10% by the time you're talking terabytes. For rough estimates you can treat them as the same thing. When you're buying disks or reading a cloud bill, you can't.
The latency ladder Slide 4
These are worth learning by heart, at least roughly. They let you spot a design that assumes something impossible — like calling 50 different services one after another and still answering the user quickly.
| Operation | Approx time | Relative scale |
|---|---|---|
| L1 cache reference | ~0.5 ns | |
| Main memory (RAM) read | ~100 ns | |
| SSD random read (NVMe) | ~100 µs | |
| Round-trip inside a datacenter | ~500 µs | |
| Spinning-disk (HDD) seek | ~10 ms | |
| Cross-region RTT (EU ↔ US-East) | ~80 ms | |
| Cross-continent RTT (EU ↔ APAC) | ~200 ms |
Memory is about 100× faster than an SSD. An SSD is about 100× faster than a spinning hard disk. Talking to another machine in the same data center lands somewhere between memory and SSD. Talking to another region costs you tens of milliseconds that no amount of clever code will remove — light travels through fibre at only about two-thirds of its speed in a vacuum, and that sets a hard floor for every hop across the planet.
The nines, and what they cost Slide 5
"Availability" is the percentage of time your system is up, and people count it in nines: 99.9% is "three nines". Each extra nine is roughly 10× harder to reach. Past three nines, most outages stop coming from broken hardware and start coming from deploys, config changes, and human mistakes. At that point the money goes into better process, not more spare machines.
| Availability | Annual downtime | Per month | Per day |
|---|---|---|---|
| 99% two nines | ~3.65 days | ~7.2 h | ~14.4 min |
| 99.9% three nines | ~8.77 h | ~43.8 min | ~86 s |
| 99.95% | ~4.38 h | ~21.9 min | ~43 s |
| 99.99% four nines | ~52.6 min | ~4.3 min | ~8.6 s |
| 99.999% five nines | ~5.26 min | ~26 s | ~0.86 s |
You win back some of what those extra services cost you by caching answers, retrying failed calls, and still returning something useful when one part is down. But the room for error is small: 99.95% availability allows only about 22 minutes of downtime per month, and a single bad deploy can eat half of it.
QPS — from users to load Slide 6
QPS means queries per second — how many requests hit your system every second. Start from how many users you have, multiply by how much each one does, then account for the fact that traffic is not spread evenly through the day. The average tells you how many servers you need to run normally. The peak tells you how much spare capacity you need for the busiest evening of the week.
Peak is 2–5× the average
Most consumer apps get 2–5× their daily average at the busiest hour. A chat app rises gently. A live sports stream spikes brutally.
Count reads and writes separately
Apps that read 10× more than they write need a very different design from ones that read 100× more. Never lump them together.
Plan for double
Size for the traffic you expect in 12–18 months, not today's. Buying slightly too much is cheap. Rebuilding the system in a panic is not.
Carry both numbers to the end
The average and the peak answer different questions and cost very different amounts. Keep both all the way through to your final answer.
Storage — four multipliers Slide 7
Forget any one of these and your answer will be roughly ten times wrong.
Size the typical item and the big ones
A "post" might be 400 bytes of text on average, but carry a 2 MB photo. Break it down: text, metadata, attachments, indexes. Then add 20–30% for the overhead of storing it.
Copies: ×3, often more
Most databases keep 3 copies of everything in one region. Add a copy in another region for disaster recovery and you're at 4–6×. Erasure coding wins some space back, but costs CPU and speed.
Growth stacks on itself
If both your user count and the amount each user stores are growing, storage grows by the two multiplied together. Three years of 1.5× growth is 3.4×, not 4.5×.
The costs nobody counts
Indexes add another 30–80%. Logs are often bigger than the data they describe. And backups multiply the whole figure all over again.
Bandwidth — QPS × payload Slide 8
The maths here is easy. The catch is that data flowing in and data flowing out are rarely equal — and it's the data flowing out of the cloud that lands on your bill.
ingress_Bps = write_QPS × avg_request_size
A network card sold as "10 Gbps" moves 10 gigabits per second, which is only about 1.25 GB of actual data per second — and less once you subtract protocol overhead and encryption. Plan on getting 60–70% of the advertised number when you're busy. Mixing up bits and bytes makes you wrong by a factor of 8, and it is by far the most common mistake.
Reading usually costs far more than writing
A video site receives about 1 MB per upload but sends about 500 MB per view — 500× more out than in. Messaging apps are roughly balanced. Search takes tiny queries and returns tiny answers, but does it constantly.
Where the bill hides
Inside one availability zone, network traffic is essentially free. Between zones it costs cents per GB. Between regions, or out to the public internet, it costs many times more. So estimate outbound traffic by where it's going.
Worked example: a social feed Slide 9
A Twitter-like app called Quill. We'll work out how much storage it needs, how many reads per second it serves, and how much data it sends out, all for the home timeline.
Worked example: photo sharing Slide 10
A photo app called Pebble. Here the photos themselves dominate both storage and outbound traffic — the exact opposite shape from Quill.
Where envelope math goes wrong Slide 11
- Mixing up bits and bytes. 10 Gbps is 1.25 GB/s, not 10. That's an 8× error, and it's the worst one you can make.
- Sizing for the average instead of the peak. If you have just enough capacity for an average day, you'll be on fire during the busy hour.
- Forgetting copies and indexes. Three replicas, two indexes and a backup can easily multiply your raw data by 8.
- Forgetting growth. Today's storage number is not your target. Size for 18–24 months from now.
- Fake precision. "4,728,193 QPS" is less convincing than "about 5 million", because the extra digits hide the fact that you guessed the inputs.
- Ignoring the rare-but-huge cases. A handful of viral posts or celebrity accounts can outweigh millions of ordinary ones. Give those their own line in the estimate.
Rules that keep you honest Slide 12
Round hard
One meaningful digit is plenty. "About 50k QPS" is exactly the right level of precision for this kind of work.
Give a range
"Somewhere between 8 and 12 PB" is honest about what you don't know, and gives the person reviewing it something concrete to argue with.
Check the answer against reality
If your maths says one machine handles 10 million requests a second, or that a region needs 50 PB of memory, stop. Compare it to a real system you know.
Show your inputs
The value of an estimate is the list of assumptions behind it. Anyone should be able to change one number and redo the whole thing in 30 seconds.
You are not trying to be right to four decimal places. You are trying to be right within a factor of two, and fast enough to try five different "what if we…" scenarios before lunch.
Active recall
Cover the answers. Say each number out loud before you tap to check.