Capacity Estimation

In one line

QPS/RPS, storage, bandwidth, memory — the arithmetic that makes every HLD answer defensible.

0/9 · 0%

Think of it like this

A caterer estimating how much food to cook for a wedding by asking 'how many guests, how many plates each' rather than guessing randomly. Rough, round numbers based on real assumptions beat no numbers at all.

Key ideas

01
Start from a DAU number: e.g. 100M MAU → 60M DAU → 30M daily active writers.
02
QPS estimate: actions-per-user-per-day × DAU / 86,400 seconds; peak = 3–10x average.
03
Storage: bytes-per-record × records-per-day × retention days; size columns honestly (UUID=16B, timestamp=8B, text~public).
04
Bandwidth: read-bytes-per-request × read QPS (and peak) — mostly served by CDN for media.
05
Memory: hot-working-set math for caches (e.g. only 10% of objects are hot; cache 10% × bytes).
06
Sanity anchors: 1 req/s = 86.4k/day; 1 GB/s ≈ 8.6 TB/day; 10 TB ≈ 10k GB disks.
07
The trick is ORDER OF MAGNITUDE: '~10k reads/s peak' is the answer; '9,847.3 reads/s' is not.

Java / Spring map

→
Calculation spreads as tables; present in k/M/G with three fudge factors stated.

Code & diagrams

CapacityEstimate.mdmarkdown

The worked example that ends the 'I can't do math' fear.

Goal: "like a mini-Twitter" — 200M MAU, 20M DAU, 5 actions/day/user.

1) QPS
   actions/day  = 20M × 5  = 100M
   avg QPS      = 100M / 86_400 ≈ 1,160/s
   peak (5x)    ≈ 5,800/s writes      reads ≈ 3:1 → ~17k/s reads

2) Storage
   tweet  ≈ 280B text + 1KB meta ≈ 1.3 KB
   tweets/day = 20M × 2 = 40M  →  40M × 1.3KB ≈ 52 GB/day
   × 5 years (retention)        ≈ 95 TB + overhead → ~110 TB
   Shard: 32 nodes → ~3.5 TB each (under the 8TB disk ceiling)

3) Bandwidth
   media tweet 25KB avg → 10M/day → 250 GB/day ≈ 2.9 MB/s avg
   peak ×10 ≈ 29 MB/s  (a 10G NIC laughs)

4) Cache memory
   hot feed reads: 17k/s × 25KB response × 10% hot keys → ~42 MB/s served from cache;
   cache 48h of hot keys → cache cluster sized at a few hundred GB → trivial with Redis.

Numbers in hand, you can now justify: SQL for users, Cassandra for tweets,
Redis for feeds, CDN for media — with gigabytes and gigawatts as evidence.

Explain without notes

Redo the estimate for a 2M-DAU e-commerce with a 10x launch-day spike — say your storage and QPS.

Practice

Drive the numbers for the chat system: message QPS, 5-year storage, and WebSocket connection memory.

Trade-offs

↔
All estimates are guesses with claimed error bars; the skill is stating assumptions, not precision.

Run it in production

You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:

Stateful · Bottlenecks & capacity planning

USE/RED, Little's Law, the utilisation knee, and profilers.

Stateful · Load testing with k6

Open vs closed models and SLO thresholds that gate CI.

Completion checklist

I can produce QPS + storage numbers for any prompt in ~5 minutes.

Back to phase

Command Palette