Capacity calculator
Every design question starts with a number: how much traffic, how much storage, how much bandwidth. Change an assumption and watch what it costs — the arithmetic is shown beside each figure, because reproducing it on a whiteboard is the actual skill.
Assumptions
Estimate
- Average QPS
- 231
- Peak QPS
- 694
- Writes per second
- 23
- Reads per second
- 208
- New data per day
- 2 GB
- Stored after 3 years
- 6.57 TB
- Peak egress
- 1.25 MB/s
= 1 million users × 20 requests ÷ 86,400 seconds
The daily average, which nothing is actually sized against.
= 231 × 3 peak multiplier
The number that sizes the fleet. Capacity planned against the average falls over every evening.
= 231 × 10% writes
Usually the bottleneck: a single primary absorbs writes, while reads spread across replicas.
= 231 × 90% reads
What caching and replicas are for.
= 23 writes/s × 86,400 × 1 KB
= 2 GB/day × 365 × 3 years × 3 replicas
Replication multiplies the bill. Forgetting it is the most common way an estimate comes out three times too small.
= 625 peak reads/s × 2 KB
Bandwidth is often the real cost, and the one people forget to estimate at all.
Getting it wrong in the usual ways
- Sizing the fleet against the daily average. Traffic is never flat, and a system planned on the average falls over every evening.
- Forgetting replication. Three replicas is three times the storage bill, and it is the single most common way an estimate lands three times too small.
- Deriving storage from total requests rather than from writes. At a 10% write ratio that is a tenfold error.
- Not estimating bandwidth at all. For anything serving media it is usually the largest line on the bill.
- Quoting seven significant digits. The inputs are guesses; the output is an order of magnitude, and saying “roughly 3,000 QPS at peak” is the correct precision.