Capacity Estimator
The architecture half of a system design round gets all the preparation. The part candidates fumble is the two minutes where someone asks how much traffic and how much storage. It is four conversions in the right order, and three of them have a trap attached. Move the sliders and watch which resource actually constrains the design — because naming the bottleneck is the answer, and the arithmetic is only how you get there.
Five worked systems: messaging, photo sharing, URL shortener, video streaming and ride hailing.
Messaging. Write-heavy and tiny payloads. QPS dominates; the storage bill is almost an afterthought.
Bytes on disk are the binding constraint. Talk about tiering cold data to object storage, whether ten years of retention is a product requirement or an assumption, and whether the replication factor has to be three everywhere.
Inputs
The four conversions, in order
| 1 | Per day → per second 20bn writes/day ÷ 86,400 Divide by 86,400, not by 24 and not by 3,600. It sounds obvious and it is the most common slip in the room. | 231k write QPS |
| 2 | Average → peak (231k + 347k) × 4 You size the fleet for the peak. Quoting the average and moving on is the single fastest way to signal you have not built anything that had a Friday night. | 2.3m peak QPS |
| 3 | Writes → bytes on disk 20.0 TB/day × 3 ÷ 2 × 1825 days Replication and retention are both multipliers and both get dropped. Three copies kept for five years is fifteen times the naive figure. | 54.8 PB |
| 4 | Bytes/sec → bandwidth 1.39 GB/s × 8 bits Networks are sold in bits and storage in bytes. Forget the factor of eight and you are out by an order of magnitude in whichever direction is least convenient. | 11 Gbps egress |
Where the peak actually sits
The area under this curve is fixed — it is the day’s total requests, which the multiplier cannot change. So raising the peak does not add traffic, it moves traffic from the overnight hours into the evening. At 4× the quiet hours run at 1.6k QPS while the evening hits 2.3m. You buy the tall bar and you pay for it for twenty-four hours, which is the entire economic argument for autoscaling.
What the cache is and is not doing for you
The cache changes the read path and nothing else. Storage is unaffected — you still hold 54.8 PB whatever the hit rate. Writes are unaffected; they go through. And the number that matters for database sizing is the 694k QPS that miss, not the 1.4m that arrive. A candidate who quotes the arriving figure has just over-provisioned the most expensive tier in the system by 2×.
Shortcuts worth knowing cold
1 million per day ≈ 12 per second 1,000,000 ÷ 86,400. The single most useful conversion in the room. |
1 billion per day ≈ 11,600 per second Same division, three orders up. Anything at web scale starts here. |
1 Gbps ≈ 125 MB per second Eight bits to the byte. Networks are sold in bits, storage in bytes. |
1 TB per day ≈ 365 TB per year Round the year to 365 and do not apologise for it. |
A year has ≈ 31.5 million seconds π × 10⁷ is within half a percent, which is a genuinely useful coincidence. |
2¹⁰ ≈ 1 thousand, 2²⁰ ≈ 1 million, 2³⁰ ≈ 1 billion Lets you turn a bit-width into a count instantly: a 32-bit id addresses about 4 billion things. |
Estimate in decimal: 1 KB = 1,000 bytes The binary KB is 1,024, and the gap compounds to about 10% by the terabyte. It is why a 1 TB disk reports as 931 GB, and it never changes a design decision. Do the round arithmetic. |
Latency numbers you are assumed to have
| L1 cache reference | ~1 ns | Free, for practical purposes |
| Main memory reference | ~100 ns | 100× slower than L1 |
| Compress 1 KB | ~2 µs | Cheap enough to almost always do |
| Read 1 MB from memory | ~50 µs | |
| SSD random read | ~100 µs | 1,000× slower than RAM |
| Round trip within a datacentre | ~500 µs | The cost of one service hop |
| Read 1 MB from SSD | ~1 ms | |
| Disk seek (spinning) | ~5 ms | Why random access on disk is avoided |
| Read 1 MB from disk | ~20 ms | |
| Round trip London → California | ~140 ms | Speed of light. No optimisation beats it |
Orders of magnitude, not benchmarks. Nobody expects you to know that an SSD read is 96 µs — they expect you to know it is roughly a thousand times slower than memory and roughly a hundred times faster than a disk seek, because that is what decides where the data lives.
The five things that lose the estimation round
- Quoting the average when asked to provision. The fleet has to survive the peak. Average QPS is a billing number, not a capacity number.
- Storing one copy for one year. Replication and retention are both multipliers on the same figure, and dropping either understates storage by the whole factor.
- Treating the cache as a storage saving. It is a read-path saving. Your disk bill does not move.
- Assuming reads and writes are balanced. Ask for the ratio, or state your assumption. Most systems are somewhere between 10:1 and 1000:1 read-heavy, and the design that follows is completely different at each end.
- Producing a number without saying what it constrains. “About 1.4 million peak QPS, so this is a sharding problem before it is a schema problem” is the answer. A number on its own is arithmetic, and arithmetic is not what is being tested.