Capacity planning is about making explicit assumptions, then turning them into numbers you can design around
In system design interviews, capacity planning isn’t about perfect accuracy—it’s about producing reasonable order-of-magnitude estimates and using them to justify architecture choices. The mental model is: (1) pick a small set of key drivers (users, actions per user, object sizes), (2) convert to rates (per second) and volumes (per day/month), (3) apply peak factors and overhead, and (4) sanity-check against real-world constraints (network, disk, replicas). Strong answers narrate assumptions, show the math, and tie outputs directly to decisions like caching, sharding, queueing, partitioning, and replication.
A 7-step back-of-the-envelope framework you can run live in interviews
1) Start with the product metric you can defend (DAU/MAU)
Pick a user base assumption and state it clearly (e.g., “10M MAU, 20% DAU => 2M DAU”). If you’re unsure, propose a range and proceed with one number, noting sensitivity.
2) Translate users into actions per day (requests/day)
Define 1–3 critical user actions that drive load (feed reads, message sends, uploads). Use “actions per active user per day” (APU). Example: 2M DAU * 30 feed opens/day => 60M feed opens/day.
3) Convert daily totals to average QPS and peak QPS
Average QPS ≈ requests/day ÷ 86,400. Then apply a peak factor (often 3–10× depending on diurnal patterns, launches, and retries). Call out whether peaks are global or regional.
4) Split reads vs writes and identify hotspots
Estimate read:write ratio and any fanout behavior. Example: timeline reads are heavy and bursty; writes might be lighter but create downstream work (indexing, notifications). This step often changes storage and bandwidth needs more than the base QPS.
5) Estimate payload sizes to get bandwidth (MB/s, Gbps)
For each critical API, estimate request size and response size (headers + JSON/proto + media references). Bandwidth ≈ QPS * bytes/req. Use response sizes for read-heavy systems; include TLS/HTTP overhead (~10–30%) if relevant.
6) Estimate storage: per-object size, write rate, retention, replicas
Storage/day ≈ objects/day * bytes/object. Then multiply by retention (days) and replication (e.g., 3x) and add index/metadata overhead (often +20–100%). Distinguish hot storage (SSD) vs cold (object storage) if lifecycle matters.
7) Sanity-check and tie numbers to design decisions
Do quick plausibility checks (e.g., “Is 5 Gbps plausible for 10M users?”). Use outputs to justify caching, CDN, partition keys, async queues, rate limiting, backpressure, and capacity buffers (commonly 30–50% headroom).
Common capacity planning mistakes interviewers notice immediately
- •Skipping assumptions and jumping to a QPS guess without showing how it was derived
- •Using average QPS only and forgetting peak traffic (or choosing an extreme peak factor without justification)
- •Mixing up units (MB vs MiB, bits vs bytes, per day vs per second) and never reconciling them
- •Ignoring read/write asymmetry (e.g., feeds and search are read-dominant; logging and ingestion can be write-dominant)
- •Forgetting fanout effects (one write causing many reads/updates/notifications)
- •Underestimating response size—metadata and pagination add up even without media bytes
- •Estimating storage but forgetting replication, indexes, thumbnails/derivatives, and retention policy
- •Treating bandwidth and storage as the same problem (high storage doesn’t always imply high network load, and vice versa)
- •Not tying estimates to design choices (cache, shard key, queue, CDN, backpressure)
- •Over-optimizing accuracy instead of producing an order-of-magnitude answer quickly and clearly
Example: Estimate capacity for a photo-sharing feed (reads + uploads)
Weak Answer
“We’ll have a lot of users, so maybe 100k QPS. Storage could be huge, like petabytes. We’ll use sharding and CDN.”
Strong Answer
Assumptions: - 10M MAU, 30% DAU => 3M DAU - Each active user opens feed 20 times/day => 60M feed reads/day - Average QPS for feed reads: 60M / 86,400 ≈ 694 QPS - Peak factor 6x (evening spikes) => ~4,200 read QPS Uploads: - 3M DAU, 0.2 uploads/user/day => 600k uploads/day - Avg upload QPS: 600k / 86,400 ≈ 6.9 QPS - Peak factor 5x => ~35 write QPS Bandwidth (feed responses): - Response includes 20 items with metadata + thumbnails URLs; assume ~40 KB/response (JSON/proto + overhead) - Peak egress ≈ 4,200 QPS * 40 KB ≈ 168,000 KB/s ≈ 168 MB/s ≈ ~1.3 Gbps (before CDN) Storage (photos): - Average photo 2 MB (compressed) - Daily new media: 600k * 2 MB ≈ 1.2 TB/day - 365-day retention => ~438 TB raw - 3x replication + 30% metadata/variants => ~1.7 PB total Design implication: - Use CDN/object storage for media; origin egress dominated by cache misses - Reads dominate; cache feed results/IDs; paginate; precompute timelines selectively - Uploads are low QPS but heavy bytes; use direct-to-object-storage upload with signed URLs and async processing (thumbnails, moderation).
Why it works
The good example is specific: it names a realistic user base, defines the high-load actions, converts daily counts to QPS correctly, and separates read-heavy feed traffic from write-heavy media bytes. It also converts response sizes into bandwidth and includes replication/overhead in storage. Communication-wise, it states assumptions, shows intermediate math, applies peak factors, and concludes with concrete architectural decisions (CDN, caching, async processing) that logically follow from the numbers.
Turn estimation into a repeatable interview skill
Knowing the formulas isn’t enough in interviews—you need to run them quickly under pressure, narrate assumptions, and adapt when the interviewer changes the scenario (more regions, different retention, higher write rate). On CrackTheOffer, you can practice capacity planning prompts with structured checklists, timed drills, and feedback-oriented rubrics so your estimates consistently lead to clear system design decisions.