I have sat in more capacity reviews than I can count, across three countries and two industries that do not forgive a wrong guess: payments and e-commerce. In every single one, the room did not settle on the prettiest diagram. It settled on whoever's numbers survived the first hard question. That skill has a name, and it is smaller and more learnable than people think.
- Estimation is not a guess dressed up in numbers. It is a small toolkit: units, a latency ladder, an uptime budget, and the discipline to round on purpose.
- Most of it can be done on a napkin, out loud, in the thirty seconds after someone asks "are you sure?"
- The worked example at the end sizes a real kind of platform, the same one a design review would actually ask you to defend.
This is not a story about a specific outage or a specific system. It is the toolkit underneath every estimate I have ever defended in a review, in Karachi, in Tokyo, and in Munich. Learn it once, and every future capacity conversation gets shorter.
The Room Believes the Number, Not the Box
An architecture diagram is a claim. A box labelled "cache" is not evidence that caching will save you; it is a hope drawn in a rectangle. What actually earns trust in a design review is the sentence right after the diagram: this shaves our origin traffic by roughly forty percent, and here is the arithmetic that says so. That sentence is what a back-of-the-envelope estimate gives you. It does not need to be exact. It needs to be defensible in the next thirty seconds, out loud, without a spreadsheet open.
Three things make an estimate defensible: knowing your units cold, knowing roughly how long things take at every layer of a system, and knowing what an uptime target actually costs you in real minutes. Master those three, and the fourth thing, a worked example under pressure, takes care of itself.
A Kilobyte Is a Small Lie If You Are Not Careful
Every estimate eventually turns into a size: a request payload, a day's worth of traffic, a year of storage. All of it rests on one scale, the power of two, and it is worth five seconds to say out loud before you use it.
| Power of two | Roughly | Unit |
|---|---|---|
| 210 | a thousand | 1 kilobyte (KB) |
| 220 | a million | 1 megabyte (MB) |
| 230 | a billion | 1 gigabyte (GB) |
| 240 | a trillion | 1 terabyte (TB) |
| 250 | a quadrillion | 1 petabyte (PB) |
The part that actually trips people up is not the table, it is the silent switch between binary and decimal. Storage vendors sell in decimal gigabytes (1,0003 bytes); your operating system counts in binary ones (1,0243). The gap between them is small on a laptop and enormous on a year of platform data. My habit: pick decimal for anything you are saying out loud in a review, say so once, and stay consistent. Nobody has ever lost an argument for rounding cleanly and admitting it.
If a Cache Hit Were a Heartbeat
Every choice between a cache, a database, and a network call is really a choice about time, and the times involved are so small that nobody's intuition works on them directly. The fix is a trick I have used to explain this to junior engineers for years: stretch one nanosecond-scale operation until it feels human, and scale everything else by the same factor.
Take an L1 cache reference, about half a nanosecond, and stretch it to one second. Everything else on the ladder stretches by the same two-billion-times factor. Here is what that does to the operations an architect actually chooses between:
Scale factor 2×10⁹, applied to Jeff Dean's widely-cited 2010 operation-time figures. Bars are proportional on a compressed scale so the smallest and largest values both stay visible.
Read that ladder as a decision, not trivia. If your cache hit costs about one second in this stretched world, a disk seek costs seven and a half months and a cross-continent round trip costs nearly a decade. That is not a rounding difference, it is a different category of decision. It is why "just add a cache" is not a nice-to-have in a high-traffic system, it is the single highest-leverage sentence an architect can say in a design review. And it is why a chatty service making five sequential cross-region calls per request is not a bug you fix later. It is a design that was never going to work.
What Each Nine Actually Buys You
"Ninety-nine point nine nine percent availability" sounds like a compliment on a slide. In a review, it should sound like a number of minutes you are allowed to be down, because that is exactly what it is. The conversion is arithmetic, not marketing, and it is worth doing once so you never have to fake confidence about it again.
| Availability | Down / day | Down / month | Down / year |
|---|---|---|---|
| 99% | 14.4 min | 7.2 hr | 3.65 days |
| 99.9% | 1.44 min | 43.2 min | 8.76 hr |
| 99.99% | 8.64 sec | 4.32 min | 52.6 min |
| 99.999% | 864 ms | 25.9 sec | 5.26 min |
Computed on a flat 30-day month and 365-day year, stated up front rather than buried, which is itself the habit this piece is arguing for.
The row worth staring at is 99.9 percent, three nines, because it is the one most cloud SLAs actually promise you, and it is conspicuously absent from most textbook tables. Three nines is not an abstraction. It is forty-three minutes a month. That is roughly one deployment gone wrong, one slow dependency timing out under load, one region hiccup. Three nines does not buy you room for two of those in the same month. When someone asks for "five nines everywhere" without asking what it costs to buy, that is the moment to bring this table back out.
Sizing a Platform That Actually Exists
Toolkits are only real once you have used them on something that matters. Take a fictional but entirely typical e-commerce platform, one that will feel familiar to anyone who has run payments or retail infrastructure at scale: 1,000,000 orders a day, 100,000 daily active users, spread across 8 regions, with an average request payload of 25 KB and a peak traffic factor of 10 to 15 times the daily average during a real sales event.
Nothing above is derived yet, it is just the starting assumptions, written down before a single calculation, exactly as the habit below is about to tell you to.
None of that took a spreadsheet, and none of it needed to be precise to be useful. It needed to be close, labelled, and fast. That is the entire skill. Everything from here is practice.
Five Habits That Make the Math Survive a Hard Question
Round on purpose, not by accident
99,987 divided by 9.1 is not a question anyone should try to answer live. 100,000 divided by 10 is the same order of magnitude and takes one second. Round before you calculate, not after.
Write the assumptions down, out loud
"1,000,000 orders a day, 8 regions, 25 KB average payload" is four sentences. Say them before the first multiplication, and anyone in the room can challenge one number instead of the whole answer.
Label every unit, every time
"5" means nothing. "5 MB" means something. The single most common estimate-review failure I have watched is a number surviving three slides with the wrong unit silently attached to it.
Separate the estimate from the buffer
11.6 QPS and "design for 116 to 174 QPS" are two different numbers doing two different jobs. Fold the peak factor in silently, and the first hard question, "what happens on the busiest day of the year," has no honest answer ready.
Sanity-check against a number you already trust
If a fresh estimate lands nowhere near a number your system has actually produced before, the estimate is wrong before the meeting is over. Every estimate I still trust today started life failing this test at least once.
An estimate does not need to be right. It needs to be close, fast, and defensible enough that the room moves on to the actual decision instead of arguing about the arithmetic.