The Capacity Planning Document Builder turns a few traffic and data assumptions into the numbers an architecture actually needs: peak queries per second, server count, bandwidth, and storage growth. These back-of-the-envelope estimates are what separate a design that survives launch from one that falls over under real load.
How it works
The tool computes each figure from standard capacity-planning arithmetic. Average QPS is daily users × requests per user ÷ 86,400 seconds per day. Peak QPS multiplies that by your peak-to-average ratio, because you must size for the busiest moment, not the average. Server count is peak QPS ÷ per-server capacity, rounded up. Storage growth is records per day × record size, projected to a year. The result is a document with every input, the computed numbers, and suggested scaling-trigger thresholds so a reviewer can see your reasoning and challenge the assumptions, not just the conclusion.
Tips and example
- Always size for peak. A system that handles average load but not the evening spike is a system that goes down every evening.
- Add overhead to storage. Multiply the raw growth figure by your replication factor and add room for indexes and backups — real storage is often two to three times the raw data.
- Set scaling triggers low. Plan to add capacity before you hit the limit, not at it, so you have time to react.
Example: 1,000,000 daily users at 10 requests each is ~116 average QPS; with a 4× peak ratio that is ~463 peak QPS, needing 5 servers at 100 QPS each, and 1M records/day at 2KB is ~730GB/year before overhead.
How to use these numbers in a design review
Capacity planning documents are most valuable not as precise forecasts but as assumption surfaces — places where colleagues can challenge an input rather than an output. When you write “5 servers,” what they are really reviewing is whether “100 QPS per server” is realistic for this workload. Getting that assumption into the document is the goal.
Structure your document to separate inputs from derived outputs, and flag which assumptions carry the most uncertainty. The single biggest risk in back-of-the-envelope planning is underestimating the peak-to-average ratio. Consumer apps routinely see 5–10× spikes during viral moments, real-world events, or marketing campaigns. If your architecture fails at 3× average, it will fail publicly.
Scaling triggers and headroom
Capacity planning is not a one-time exercise. Build in scaling triggers — thresholds at which you add capacity before you hit the limit. Common triggers:
- CPU sustained above 60–70% across the fleet for more than 15 minutes
- Request queue depth growing (inbound faster than processing for more than a few seconds)
- Storage utilisation above 70% with less than 4 weeks to exhaustion at current growth rate
The document this builder produces includes suggested thresholds. Adjust them for your latency tolerance and how fast you can provision. If you are on auto-scaling cloud infrastructure, these thresholds feed directly into your autoscaling policy.
Replication and overhead factor for storage
The raw daily growth figure in the document represents the data your application writes. Real storage requirements are larger:
- Replication — most production databases run 2–3 replicas, multiplying write volume
- Indexes — B-tree and other indexes commonly add 20–40% of the raw table size
- Write-ahead logs / binlogs — especially significant in high-write systems; can temporarily double storage
- Backups and snapshots — daily snapshots with a 30-day retention multiply the baseline by ~30
A pragmatic rule for planning: multiply the raw storage figure by 3–5 for a production-ready estimate. Provision for two years of growth, not one.