What it is
Capacity estimation is the two minutes of arithmetic — requests per second, bytes stored, bytes moved — that turns a vague prompt (“design X at scale”) into design constraints. The output isn’t the numbers; it’s the conclusion each number forces (“read-heavy → caching is the architecture”).
When you care
Nearly every system design interview opens with it, and most candidates do it wrong in the same way: they produce numbers and move on. Interviewers aren’t checking your division — they’re checking whether you know what the numbers are for. An estimate that doesn’t change the design wasn’t worth computing.
The three estimates
| Estimate | Formula | The conclusion it forces |
|---|---|---|
| QPS | daily volume ÷ ~100K sec/day; peak = 2–10× average | Whether you need caching, fan-out limits, how many serving nodes |
| Storage | items/day × bytes/item × retention × replication | Single DB vs sharded fleet; whether data movement dominates ops |
| Bandwidth | QPS × payload size | Whether the network, not compute, is the bottleneck (media, logs, streams) |
QPS shortcuts
- A day is ~86,400 seconds — call it 10⁵ for mental math.
- 1M/day ≈ 12/sec. 100M/day ≈ 1,200/sec. 1B/day ≈ 12K/sec.
- Peak multiplier: 2–3× for global products (load spreads with timezones), 5–10× for regional or event-driven traffic. Say which you’re assuming.
- Always derive the read:write ratio — it’s the single most architecture-shaping number. 100:1 says cache; 1:1 says the storage write path is the design.
Storage shortcuts
- Estimate the record, not the database: text record with metadata ~0.5–1 KB; a row of IDs and timestamps ~100 bytes; images ~500 KB; minutes of video ~100 MB.
- Multiply by retention and replication — 100 TB raw at RF=3 plus index and engine overhead is ~350–400 TB of disk. Forgetting the 3× is the most common estimation bug.
- Useful node ceiling: ~2–4 TB of served data per node (disk is bigger, but rebuild time and page cache say otherwise). Dataset ÷ 2 TB ≈ fleet size — and once fleet size is in the hundreds, failure is a steady state, which is itself a design conclusion.
Bandwidth shortcuts
- Bandwidth = QPS × payload. 12K/sec × 1 KB ≈ 12 MB/sec — trivial. 100K/sec × 500 KB images = 50 GB/sec — the design is now a CDN question.
- Compare against ~1–10 Gbps (0.1–1 GB/sec) usable per server NIC: that ratio sets the minimum number of edge/serving nodes for media systems.
Numbers worth memorizing
| Quantity | Ballpark |
|---|---|
| Seconds per day | ~10⁵ |
| Single Redis node | ~100K ops/sec |
| Single SQL DB (tuned) | ~5–10K writes/sec |
| Single Kafka-style partition | ~50–100 MB/sec append |
| SSD sequential read | ~500 MB/sec–3 GB/sec |
| Cross-region round trip | 50–150 ms |
| Same-region RPC | 0.5–2 ms |
| L1 read / RAM read / SSD read / disk seek | 1 ns / 100 ns / 100 µs / 10 ms |
The serving-capacity numbers matter most: they convert demand into fleet size (“300K writes/sec ÷ 10K per DB node = 30 shards minimum”), which is the step that makes the estimate do something.
The method, compressed
- Anchor the inputs — restate the interviewer’s numbers (DAU, items/day, payload size). If none are given, propose and confirm: “100M DAU sound right?”
- Round brutally — 86,400 → 10⁵. Powers of ten only. Precision signals you’ve missed the point.
- Compute the three estimates — average QPS, peak QPS, read:write, storage, bandwidth if payloads are large.
- State the conclusion of each number out loud — this is the entire value of the exercise: “10:1 read-heavy, so the read path gets the design attention”; “1 GB/sec of media — CDN, not app servers.”
- Stop. Two minutes. The estimate is scaffolding, not the performance.
When to pick what
- Numbers given in the prompt: skip derivation, jump to conclusions — that’s what they’re for.
- No numbers given: propose standard ones (100M DAU, 100:1 reads) and confirm before computing.
- The estimate contradicts the obvious design (e.g., everything fits on one box): say so — “this fits in RAM on one server; the distributed version is for availability, not scale” is a strong senior answer.
- Mid-design follow-ups (“how many shards?”): reuse the §2 numbers — consistency between estimate and design is itself a signal.
Related
- Walkthrough: Designing a News Feed — the fan-out estimate (3.5M writes/sec) that decides an entire architecture.
- Walkthrough: Designing a Distributed Key-Value Store — fleet-size math that turns failure into a steady state and data movement into the dominant cost.
- Walkthrough: Designing a Distributed Queue — a retention estimate that reclassifies the system from router to storage.