Turn users into QPS, storage, and bandwidth for capacity planning.
Traffic
Average QPS
2.3K
Peak QPS
6.9K
Peak read QPS
6.3K
Peak write QPS
694
Storage & bandwidth
New data / day
19.07 GB
Storage over 3 yr × 3
61.19 TB
Peak read egress
6.10 MB/s
These are back-of-the-envelope estimates for sizing decisions, not exact figures. Real systems vary with caching hit rates, compression, indexes and write amplification, and uneven (bursty) traffic. Round hard, sanity-check the order of magnitude, and validate against production metrics before provisioning.
Enter your daily active users, requests per user, read/write mix, and average object size to get the numbers every system design starts with: average and peak QPS, the read/write QPS split, daily data growth, total storage over a retention window (with replication), and the peak read bandwidth your serving tier must sustain. It is the back-of-the-envelope math from the system design interview, done for you.
Keep the inputs crude and round hard — the goal is to anchor decisions like "a single database cannot serve these reads" or "we need a cache and a CDN," not to be precise to the byte. Peak QPS (average scaled by a peak-to-average factor) is what you provision for, since traffic is bursty. Treat every output as an order-of-magnitude estimate and validate against real metrics before provisioning.
Multiply daily active users by requests per user to get requests per day, then divide by 86,400 (seconds in a day) for average QPS. Because traffic is bursty, multiply that by a peak-to-average factor (commonly 2–5×) to get the peak QPS you actually provision for. This tool does both and splits the result into read and write QPS.
It depends on your audience, but 2–5× is a common starting range: consumer apps with strong daily peaks trend higher, steady B2B or global traffic trends lower. Provision for the peak, not the average — sizing for average QPS means falling over every day at peak. Measure your real ratio once you have production traffic.
It is intentionally rough — an order-of-magnitude sanity check, not a precise figure. Real usage shifts with cache hit rates, compression, index and write amplification, and uneven traffic. Its value is anchoring architecture decisions early; always reconcile against production metrics before committing hardware.