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.