Back-of-the-envelope estimation
Before you choose a design, estimate it: QPS, storage over 5 years, bandwidth, cache size. A two-minute calculation rounded to one significant figure rejects the wrong architecture cheaply — and tells you which resource will break first.
Two engineers argue for an hour about whether to cache a feed in memory or read it from disk on every request. A third grabs a napkin: 100M users, each opening the app 5 times a day, is ~6,000 reads/second average and maybe 30,000 at peak; the hot feed set is ~50 GB, which fits in RAM on a couple of machines. The argument is over in ninety seconds — not because the napkin is precise, but because it’s right to within an order of magnitude, and that’s all the decision needed. Jeff Dean built much of Google’s infrastructure on exactly this habit: estimate the design before you build it.
Why estimate before you build
In ten minutes you’ll have a method that lets you kill bad architectures before anyone writes a line of code — and know exactly which resource will break first.
A back-of-the-envelope calculation is a fast estimate built from a few known numbers and order-of-magnitude reasoning, used to decide which design is plausible before writing code or provisioning hardware. The point is not precision — it’s elimination. If your estimate says a single Postgres instance must absorb 400,000 writes/second, you don’t need to benchmark to know the single-instance design is dead; you’ve rejected it for the price of a napkin.
The junior instinct is to skip this and “just build it, then measure.” That works until the thing you built took three weeks and the measurement says it was the wrong shape all along. The senior instinct is to spend two minutes up front asking: what is the load, what does it cost in each resource, and which resource hits its ceiling first? You estimate four quantities — QPS (request rate), storage (bytes at rest, projected over years), bandwidth (bytes in motion per second), and memory (working set you’d want hot in cache) — because those four are what actually run out.
The two number tables you keep in your head
Estimation rests on two cheat sheets. First, the powers of two, so you can convert “how many bytes” into “how many machines” instantly:
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 PBSecond, Jeff Dean’s latency numbers — the relative cost of operations, which tell you which step in a design dominates:
L1 cache reference 0.5 ns
Main memory reference 100 ns (~200× slower than L1)
Round trip within datacenter 500,000 ns (0.5 ms)
Disk seek 10,000,000 ns (10 ms — ~20× a DC round trip)
Send packet CA→Netherlands→CA 150,000,000 ns (150 ms cross-region)The shape that matters: memory is ~100,000× faster than a disk seek, and a cross-region round trip is ~300× a same-datacenter one. When a design says “and then it reads from disk per request” or “and then it makes a synchronous cross-region call,” these numbers tell you the cost without measuring.
▸Why this works
Why round to one significant figure? Because the inputs are already guesses. You don’t know the user count to two digits — you know it’s “about 100 million,” not 97.3 million. Carrying false precision (computing 6,142 QPS) creates an illusion of accuracy the inputs can’t support, and it slows the arithmetic. Round aggressively: 86,400 seconds/day becomes 100,000 (or ~10^5); 100M users becomes 10^8. The whole discipline is order-of-magnitude reasoning — you are deciding between “fits on one box” and “needs a fleet,” and a 2× error doesn’t change that answer. If a 2× error would change the design, that’s your signal to measure, not estimate.
A worked estimate: design-a-Twitter
Take the canonical interview prompt. Assume 300M monthly users, 150M daily active, each posting on average 2 tweets/day and reading their timeline such that the system serves far more reads than writes.
Write QPS. 150M users × 2 tweets = 300M tweets/day. There are ~86,400 seconds/day — round to 10^5 (100,000). So 3×10^8 ÷ 10^5 = 3,000 writes/second average. Peak is spikier than average; multiply by ~3 for a safety factor → ~10,000 writes/sec peak.
Read QPS. Reads dominate social feeds — assume a 100:1 read:write ratio (people scroll far more than they post). 3,000 × 100 = 300,000 reads/second average, ~1M at peak. This single number already shapes the design: 300K reads/sec will not come off a single database, so a read path with caching or fan-out-on-write is mandatory — you knew that before drawing a box.
Storage over 5 years. A tweet is ~300 bytes of text + metadata; round to ~10^3 bytes to be safe. 3×10^8 tweets/day × 10^3 bytes = 3×10^11 bytes/day = ~300 GB/day of text. Over 5 years: 300 GB × 365 × 5 ≈ ~550 TB. Media (images/video) dwarfs this — if 10% of tweets carry a 1 MB image, that’s 3×10^7 × 10^6 = 3×10^13 = ~30 TB/day, ~50 PB over 5 years. The estimate just told you the real storage problem is media, not text — by three orders of magnitude.
Cache size. You don’t cache 5 years of tweets; you cache what’s hot. Assume 20% of daily reads hit 80% of their volume on recent tweets, and you want ~1 day of tweets hot: 300 GB of text fits comfortably in RAM across a few machines (a modern box holds 256–512 GB). So the feed cache is cheap; the media store is the expensive, hard part — again, known before any code.
When an estimate changes the design
The whole exercise pays off when a number crosses a threshold. A few load-bearing thresholds worth memorizing:
- Fits in RAM on one box? If the hot working set is < ~256 GB, a single cache node (or a small replicated set) is viable; above that you must shard the cache.
- Fits on one database? A single primary handles roughly low-thousands of writes/sec comfortably; tens of thousands says sharding or a different store. Our 10K-peak write number is right at the line — it’s the signal to plan sharding now, not later (the lesson from vertical-vs-horizontal: don’t discover the ceiling during an outage).
- Bandwidth feasible? 300K reads/sec × an average 5 KB response = 1.5 GB/sec = ~12 Gbps of egress — fine across a fleet, but it tells you a single 10 Gbps NIC won’t serve it, and it puts a real cost number on the CDN bill.
Together these three thresholds tell you whether the design fits on existing hardware, where you need to shard, and what the bill looks like — all before you draw a single architecture box. Miss any one of them and you’ll discover it at 2 AM during an outage.
▸Common mistake
The most common estimation error isn’t arithmetic — it’s using the average when the system is sized by the peak. Average QPS is total / 86,400, but traffic is bursty: a consumer app can see 3–10× its daily average at the evening peak, and a flash sale or a viral event far more. Provision for the daily average and you fall over exactly when it matters. Always carry a peak-to-average multiplier (start with 2–3× and adjust for your domain), and remember that retries during an incident add load precisely when you’re already at peak — the feedback loop that turns a brownout into an outage.
A service has 100M daily active users, each making 10 requests/day. Estimating to one significant figure, what is the average QPS, and roughly what peak should you provision for?
Your napkin says a feature needs ~3,000 writes/sec average on a store where a single primary comfortably does low-thousands. The estimate could be off by 2×. What's the right move?
Because the inputs to an estimate are themselves guesses (about 100M users, not 97.3M), you should round every result to one _______ figure — carrying more digits invents a precision the inputs can't support and only slows the arithmetic.
- 01What four quantities do you estimate, and why those four?
- 02Walk the design-a-Twitter write→read→storage estimate at one significant figure.
- 03Name two thresholds where the estimate changes the design, and the peak-vs-average trap.
Back-of-the-envelope estimation is the senior habit of deciding which design is plausible before building it, by estimating four quantities — QPS, storage (projected over years), bandwidth, and memory — to within an order of magnitude. It rests on two cheat sheets: the powers of two (2^30 ≈ 1 GB, so bytes convert to machines instantly) and Jeff Dean’s latency numbers (memory ~100× faster than a DC round trip, ~100,000× faster than a disk seek, a cross-region hop ~150 ms), which tell you which step in a design dominates. Always round to one significant figure — the inputs are guesses, so false precision is a lie — and always size for the peak, not the average (3–10× higher, made worse by retry storms). The worked design-a-Twitter estimate shows the payoff: in two minutes it reveals that 300K read QPS forces a cache/fan-out read path and that media storage (~50 PB) dwarfs text by 100× — two design-changing facts found on a napkin, not in a three-week prototype. Now when you see a design proposal, reach for a napkin first: estimate QPS, check it against the single-box ceiling, project storage, and you’ll know in two minutes whether the conversation is worth continuing.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.