Capacity Estimation
The process of estimating the load, traffic, and storage requirements for a system to ensure it can scale effectively.
Step 01 · Concept Snapshot
Capacity estimation = rough math before architecture
Use assumptions to estimate how much traffic, storage, bandwidth, and infrastructure the system needs.
Capacity estimation is not about perfect math. It is about checking whether your design can survive the expected scale.
Choose a scenario
Read-heavy feed. Many small posts, some media. Long retention.
Step 02 · Assumption Builder
Start with assumptions
Change product assumptions and watch estimates update live.
Monthly active users
Read : Write ratio
Average payload
Data retention
Step 03 · Live System View
Assumptions become system pressure. Hover any node.
Step 04 · System Metrics
Daily Active Users
50.0M
Average QPS
584.5K
Peak QPS
1.8M
Total Storage
9.3 PB
Step 05 · QPS Simulation
Estimate average and peak QPS
Traffic is never flat. Peak multiplier is what your servers must survive.
Peak multiplier
Traffic pattern
Step 06 · Storage Estimation
Estimate storage growth
Media and replication usually dominate raw record size.
Replication
Daily raw mix · replication adds 3x on top for durability
Per day
53.5 TB
Per year
19.5 PB
Retained
97.6 PB
With 3x
292.7 PB
Step 07 · Bandwidth Estimation
Estimate bandwidth pressure
Bandwidth grows fast with payload size, even at moderate QPS.
CDN
Step 08 · Architecture Recommendation
Turn estimates into architecture choices
Add Cache
What changed: Read QPS is much higher than write QPS.
Why it matters: Repeated reads can be served from memory instead of hitting the database.
Tradeoff: Cache adds invalidation and consistency complexity.
Add Load Balancer
What changed: Peak QPS (1.8M) exceeds single-server comfort.
Why it matters: Traffic spreads across multiple API servers for headroom and failover.
Tradeoff: Adds a component that must itself be highly available.
Consider Sharding
What changed: Total storage (9.3 PB) is very large.
Why it matters: Partitioning spreads data and writes across nodes for horizontal scale.
Tradeoff: Cross-shard queries and rebalancing add significant complexity.
Step 09 · Insights & Warnings
Step 10 · Validate Your Instinct
Quick estimation checks
Calculate DAU
100M MAU, 30% daily active
Estimate write QPS
30M DAU, 2 writes/day each
Find peak QPS
Avg 1,000 QPS, peak 3x
Spot storage pressure
10% of posts have 1MB media
Choose architecture help
Read QPS is 100x write QPS
Step 11 · Solution Panel
Method walkthrough, weak-vs-strong, and interview answer.
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.