Capacity Estimation
The process of estimating the load, traffic, and storage requirements for a system to ensure it can scale effectively.
Choose a simulation
Traffic inputs
Avg QPS
12
requests/sec
Peak QPS
35
3× peak
Servers needed
1
at full peak
Req / day
1.0M
total
System under traffic
100.0K DAU
Mini Challenges
Handle 10M DAU
Build a system that can handle 10 million daily users.
Latency under 80ms
Reduce system latency below 80ms in the Scaling tab.
Survive a viral spike
Trigger a spike in the Bottleneck tab without the DB overloading.
1 year of video storage
Estimate 1 year of storage for 100K daily video uploads.
Why this exists
Capacity estimation converts product assumptions into engineering numbers: requests per second, bandwidth, storage, and component pressure. Those numbers tell you where the bottleneck will appear long before production traffic does.
Traffic is just arithmetic
Requests per second comes from users, usage frequency, and time. Once you quantify traffic, architecture choices stop being hand-wavy.
Not every request reaches storage
Caches absorb a fraction of traffic, so the database only sees cache misses. That is why hit rate matters so much.
Replication changes cost shape
Replication improves resilience and read availability, but it multiplies storage cost. Capacity planning must include that multiplier.
Key takeaways
- Compute traffic first, then decide scaling layers.
- Cache hit rate changes database load more than almost any other input.
- Peak traffic, not average traffic, usually drives system shape.
- Storage estimates must include retention and replication, not raw payload only.