Capacity Estimation for System Design — QPS, Storage, Bandwidth
Estimate users, QPS, storage, bandwidth, memory, fanout, and cost before choosing architecture.
Before you design a building, you need to know if 100 people or 1 million people will live in it — because those two cases need completely different infrastructure. Capacity estimation is system design's version of that: it turns a vague "build me a Twitter" into concrete numbers that drive every architectural decision you make.
The sequence is: anchor on one given number (DAU), derive requests per second (QPS), then estimate storage, then bandwidth, then memory. Each number follows from the last. 100M DAU → roughly 1,000 write requests/second for a typical app → 1KB per write → 86GB of new data per day. Now you know you're not building a SQLite app; you need a distributed database with replication.
Senior engineers memorize a few key constants: 1 million seconds in 11 days, 1TB ≈ 1 billion KB, a typical HTTP response is ~1-10KB, an image is ~300KB, a video minute is ~10MB. With those anchors, you can estimate any system in under 5 minutes.
Key concepts
Step-by-step approach
- 1
Anchor on one given number: DAU or MAU stated in the problem, or a clearly stated assumption.
- 2
Derive DAU from MAU if needed: DAU ≈ 40-60% of MAU for healthy consumer apps.
- 3
Separate reads from writes — they scale differently and determine different bottlenecks.
- 4
Calculate peak QPS: average QPS × 2-3× for peak (Twitter-scale gets 10× spikes during live events).
- 5
Estimate storage per record × records per day × retention period = total storage needed.
Key trade-offs
Precision vs. speed
Exact numbers aren't the point — order of magnitude matters. 10K QPS and 100K QPS demand different architectures. 100K and 120K don't.
Memory vs. latency
Caching hot data reduces latency dramatically but adds cost and consistency complexity. Estimate cache hit rate to decide whether caching is worth it.
Read replicas vs. write scaling
Most consumer apps are read-heavy (100:1 ratio). Read replicas solve read scaling cheaply; write scaling requires sharding or CQRS.
Common pitfalls
Using average instead of peak: Systems break at peak load, not average. Always calculate peak QPS and design for it.
Forgetting replication factor: If you need 10TB of storage and use 3× replication, you need 30TB of disk.
Ignoring fanout: Social graphs amplify writes. A tweet to 10M followers isn't 1 write — it's potentially millions of feed updates.
Interview questions on this topic
Practice answering these with AI feedback → Start on CrackLab
Continue learning — explore 207 more topics on CrackLab DesignHub
From Classic HLD designs (Twitter, YouTube, Uber) to LLD patterns, distributed systems, databases, and company case studies.
Related topics
Turn a product idea into a production blueprint: components, data, flows, scale, failures, and trade-offs.
Understand response time, work per second, p95/p99, and why averages hide user pain.
Distribute traffic across healthy backends using L4/L7 algorithms and health checks.