# Capacity estimation

> From daily users to requests per second, storage and bandwidth in a few lines of arithmetic.

Concept · Requirements & scale · https://levelcode.org/concepts/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

```text
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.

```text
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](https://levelcode.org/concepts/latency-numbers) and [Little's law](https://levelcode.org/concepts/littles-law).