Capacity Planning for a Backend Service

Capacity planning without load tests is guessing with a spreadsheet. The number you need first is the maximum throughput one instance can handle under your expected workload — everything else is math from that baseline.

Step 1 — Baseline throughput with load tests

• Use Gatling, JMeter, or k6 to simulate realistic request patterns against one instance; ramp up load until P99 latency degrades past the SLO or error rate rises above 0.1%
• The peak throughput before degradation is your instance capacity — if one instance handles 500 req/s before degrading, you know to run at 300-350 req/s per instance (60-70% of peak) to have headroom for traffic spikes

Step 2 — Project traffic

• Extrapolate from current traffic trends: if you're at 1,000 req/s today and growing 20% month-over-month, in 6 months you'll need capacity for 2,500 req/s
• Don't forget peak multiplier — Black Friday, end-of-month billing, Monday morning — traffic peaks may be 5-10x the daily average; design for the peak, not the average

Step 3 — Instance count calculation

• minimum instances = ceil(peak_traffic / (instance_capacity x target_utilization)) — at 2,500 req/s peak, 500 req/s per instance capacity, 70% target: ceil(2500 / (500 x 0.7)) = ceil(7.14) = 8 minimum instances
• Add buffer for rolling deployments (where one instance is unavailable) and headroom for unexpected spikes: 10-12 instances for this example

Step 4 — Autoscaling and monitoring

• Configure autoscaling to add instances when CPU or request queue depth crosses 70% — which means the fleet scales before users experience degradation rather than in response to it
• Monitor actual utilization against the capacity model; update the model quarterly as traffic patterns change and application performance is tuned