Back-of-the-Envelope Estimation
Adapted from: Alex Xu, System Design Interview – An Insider's Guide (2020), Chapter 2 — rewritten and condensed for teaching.
Interviewers often ask you to size a system before you design it: How many requests per second? How much storage over five years? How many servers? Jeff Dean of Google describes these back-of-the-envelope calculations as quick estimates built from thought experiments and well-known performance numbers. Their purpose is to show which designs could meet the requirements. They are not meant to give precise answers.
You need three sets of reference numbers to do this well: powers of two for data sizes, latency numbers for how fast operations are, and availability numbers for how much downtime an SLA allows.
What you'll be able to do after this lesson:
- Convert between bytes, KB, MB, GB, TB, and PB without hesitation.
- Rank common operations (memory, disk, network) by latency and draw design conclusions from them.
- Translate an availability percentage into allowed downtime.
- Estimate QPS, peak QPS, and storage from a set of stated assumptions.
Powers of Two
Distributed systems deal with huge data volumes, but the arithmetic is basic. A byte is 8 bits, and one ASCII character takes one byte. Every larger unit is a power of two:
| Power | Approximate value | Full name | Short name |
|---|---|---|---|
| 2¹⁰ | 1 thousand | 1 kilobyte | 1 KB |
| 2²⁰ | 1 million | 1 megabyte | 1 MB |
| 2³⁰ | 1 billion | 1 gigabyte | 1 GB |
| 2⁴⁰ | 1 trillion | 1 terabyte | 1 TB |
| 2⁵⁰ | 1 quadrillion | 1 petabyte | 1 PB |
The useful shortcut: each step up multiplies by about 1,000. Strictly, 2¹⁰ = 1,024, and the binary units are sometimes written KiB, MiB, and so on. In an estimate, the 2.4% difference doesn't matter, so treat 1 KB as 1,000 bytes and 1 TB as 1,000,000 MB.
Latency Numbers Every Programmer Should Know
Around 2010, Dean published typical durations for common computer operations. Hardware has improved since then and some figures are dated. What still holds is the relative speed of these operations, which spans many orders of magnitude.
| Operation | Latency | Readable |
|---|---|---|
| L1 cache reference | 0.5 ns | |
| Branch mispredict | 5 ns | |
| L2 cache reference | 7 ns | |
| Mutex lock/unlock | 100 ns | |
| Main memory reference | 100 ns | |
| Compress 1 KB with Zippy (Snappy) | 10,000 ns | 10 μs |
| Send 2 KB over a 1 Gbps network | 20,000 ns | 20 μs |
| Read 1 MB sequentially from memory | 250,000 ns | 250 μs |
| Round trip within the same data center | 500,000 ns | 500 μs |
| Disk seek | 10,000,000 ns | 10 ms |
| Read 1 MB sequentially from the network | 10,000,000 ns | 10 ms |
| Read 1 MB sequentially from disk | 30,000,000 ns | 30 ms |
| Send a packet California → Netherlands → California | 150,000,000 ns | 150 ms |
Units: 1 ns = 10⁻⁹ s · 1 μs = 10⁻⁶ s = 1,000 ns · 1 ms = 10⁻³ s = 1,000 μs = 1,000,000 ns.
One way to feel the scale is to stretch time so that 1 ns lasts 1 second. A main-memory reference then takes almost 2 minutes, a disk seek about 4 months, and the transatlantic round trip about 5 years. Interactive charts of these numbers, adjusted year by year, exist online. The 2020 version shows the same pattern.
What the numbers tell you
- Memory is fast; disk is slow. Reading from RAM is orders of magnitude quicker than reading from disk.
- Avoid disk seeks where you can.
- Simple compression is cheap. Compressing 1 KB takes microseconds.
- Compress before sending data over the internet. Network transfer costs far more than the CPU time spent compressing.
- Data centers are far apart. A request between regions takes over a hundred milliseconds no matter how fast the servers are.
Check: reading the latency table
Latency intuition
1 / 3Roughly how many times slower is a disk seek (10 ms) than a main memory reference (100 ns)?
Pick an answer to see if you are right.
Availability Numbers
High availability means a system keeps operating for a long, uninterrupted stretch of time. It is measured as a percentage of uptime: 100% means zero downtime, and most real services fall between 99% and 100%.
A service level agreement (SLA) is a formal agreement between a service provider and its customers that defines the uptime the service will deliver. The major cloud providers (Amazon, Google, Microsoft) set their SLAs at 99.9% or higher. Uptime is usually described in nines, and each extra nine cuts the allowed downtime by a factor of 10.
| Availability | Downtime per day | per week | per month (30 d) | per year (365 d) |
|---|---|---|---|---|
| 99% | 14.4 min | 1.68 h | 7.2 h | 3.65 days |
| 99.9% | 1.44 min | 10.1 min | 43.2 min | 8.76 h |
| 99.99% | 8.64 s | 1.01 min | 4.32 min | 52.6 min |
| 99.999% | 864 ms | 6.05 s | 25.9 s | 5.26 min |
| 99.9999% | 86.4 ms | 605 ms | 2.59 s | 31.5 s |
Every row comes from one formula: downtime = (1 − availability) × period. For example, 99.9% of a day leaves 0.001 × 86,400 s = 86.4 s, or about 1.44 min.
Practice: downtime budget
Implement downtime_seconds(availability_pct, period_seconds), which returns the allowed downtime in seconds. The script reads an availability percentage and prints the budget per day (seconds) and per 365-day year (minutes).
Beyond the chapter: combining availabilities
Real requests usually pass through several components, and the overall availability depends on how they are connected:
- In series (the request needs all of them): multiply the availabilities. A web tier at 99.9% that depends on a database at 99.9% gives 0.999 × 0.999 ≈ 99.8%, which roughly doubles the downtime.
- In parallel (any one of them is enough, as with redundant replicas): the system fails only if every copy fails at once. Two independent 99.9% replicas give 1 − 0.001² = 99.9999%.
This is the arithmetic behind Chapter 1's rule to "build redundancy at every tier." In practice, failures are often correlated (a shared power supply, a bad deploy), so the parallel figure is an upper bound.
Check: availability
Nines and downtime
1 / 2Your SLA promises 99.99% monthly uptime (30-day month). An outage has already lasted 3 minutes this month. About how much downtime budget remains?
Pick an answer to see if you are right.
Worked Example: Twitter QPS and Storage
The numbers below are made up for practice. They are not Twitter's real figures.
Assumptions (write these down first):
- 300 million monthly active users (MAU)
- 50% of them use the service daily
- Each daily user posts 2 tweets per day on average
- 10% of tweets include media
- Data is kept for 5 years
Queries per second
- Daily active users (DAU) = 300 M × 50% = 150 M
- Tweet QPS = 150 M × 2 tweets ÷ 86,400 s/day ≈ 3,472, which rounds to ~3,500 Shortcut: a day has about 10⁵ seconds, so 300 M tweets/day ÷ 10⁵ ≈ 3,000. That is close enough for a first pass.
- Peak QPS: assume peak traffic is twice the average, so 2 × 3,500 = ~7,000
Media storage
Only media storage is estimated here, since it dominates. A tweet's ID (64 bytes) and text (140 bytes) are tiny next to a 1 MB media file.
- Media per day = 150 M users × 2 tweets × 10% × 1 MB = 30 M MB = 30 TB/day
- Five-year media = 30 TB × 365 × 5 = 54,750 TB ≈ 55 PB
Notice the method: each line multiplies through a chain of labeled quantities (users → tweets → media tweets → bytes → time), so the units check themselves.
Practice: generalize the estimate
Turn the worked example into a function so you can rerun it under different assumptions. Implement estimate(mau, daily_ratio, posts_per_user, media_ratio, media_mb, years) and return a dictionary with keys dau, qps, peak_qps, media_tb_per_day, and total_media_pb. Use decimal units (1 TB = 1,000,000 MB, 1 PB = 1,000 TB), 365-day years, and peak = 2 × average.
Input is one line: mau daily_ratio posts_per_user media_ratio media_mb years.
| Case | mau | daily_ratio | posts | media_ratio | media_mb | years |
|---|---|---|---|---|---|---|
| Worked example | 300000000 | 0.5 | 2 | 0.1 | 1 | 5 |
| Bigger app | 1000000000 | 0.2 | 5 | 0.05 | 2 | 10 |
| Text only | 10000000 | 1 | 1 | 0 | 1 | 3 |
Tips for the Interview
The interviewer mostly cares about your process. A clean, well-reasoned chain of estimates matters more than the exact final number.
- Round aggressively. Nobody expects you to work out 99,987 ÷ 9.1 in your head. Call it 100,000 ÷ 10 = 10,000 and move on. Useful roundings: a day is about 10⁵ seconds, a year is about 3 × 10⁷ seconds, and 2¹⁰ is about 10³.
- Write down your assumptions. You'll refer back to them, and the interviewer can correct one without throwing away your whole calculation.
- Label every unit. Does "5" mean 5 KB or 5 MB? Writing "5 MB" removes the ambiguity and catches mistakes of a factor of 1,000.
- Practice the usual estimates: QPS, peak QPS, storage, cache size, and number of servers.
Check: putting it together
Estimation practice
1 / 4An app has 20 million DAU, and each user makes 50 read requests per day. Using a day ≈ 10⁵ seconds, what is the approximate average read QPS?
Pick an answer to see if you are right.
Key Takeaways
- Treat each power of two (KB → MB → GB → TB → PB) as about ×1,000.
- Memory is about 100,000× faster than a disk seek. Cache hot data, compress data before sending it over the network, and avoid cross-region round trips on the critical path.
- Each extra nine of availability cuts allowed downtime by 10×. Components in series multiply their availabilities, and redundancy in parallel raises the total.
- Estimate by chaining labeled quantities from written assumptions, then round freely.
Previous lesson: Scale From Zero to Millions of Users.
Next lesson: A Framework for System Design Interviews — the four-step process for scoping, designing, deep-diving, and wrapping up in a 45-minute interview.