Capacity estimation

Capacity estimation (back-of-the-envelope maths) gets you the right order of magnitude for traffic, storage and bandwidth in a few minutes, so you know whether a design needs one machine or a hundred.

#The formulas

requests/s (avg)  = daily actions / 100,000          (a day is ~86,400 s; round to 10^5)
requests/s (peak) = average × peak factor (2–10×)
storage           = records/day × bytes/record × days kept × replicas × overhead (1.2–2×)
bandwidth         = requests/s × bytes/response      (×8 for bits per second)
cache size        = distinct items read/day × hot fraction (~20%) × bytes/item
concurrency       = requests/s × seconds per request (Little's law)

#A worked example

10 million daily users each open a feed 20 times a day, and 5% post a 1 KB post daily.

feed reads: 10^7 × 20 / 10^5   = 2,000/s average → ~10,000/s at a 5× peak
posts:      10^7 × 0.05 / 10^5 = 5/s → 25/s peak
storage:    500,000 posts × 1 KB = 500 MB/day ≈ 180 GB/year, ×3 replicas ≈ 550 GB/year

Conclusions: writes are tiny, reads need caching or replicas, and storage fits comfortably on one database for years.

#Habits that keep estimates honest

• Write each assumption on its own line so it can be challenged.
• Keep reads and writes separate; they scale differently.
• Size for the peak, not the average.
• Divide bits by eight: network speeds are in bits, storage in bytes.
• End every estimate with a decision ("one primary is enough", "we need a CDN").

The System Design roadmap's estimation lesson works through a full example; see also latency numbers and Little's law.