capacity-planning

Start by forecasting demand in business terms (growth rate plus event multipliers), then translate to system units like requests/s. Identify each critical-path service's first breaking constraint, load test to find the latency knee, and write the plan as metric triggers with lead times rather than calendar dates.

Set headroom based on how fast you can add capacity: 50-60% utilization targets for stateful or slow-to-scale systems like databases, and 70-75% for autoscaled stateless fleets. Always verify N-1 survivability, meaning losing one AZ or node at peak must keep you under the knee.

Load tests with mocked databases, warm caches, or no client retries overstate real capacity several-fold. Test at production parity with real endpoint mixes and payload sizes, and measure where p99 latency leaves the SLO rather than where errors start, since systems degrade before they fail.

No, capacity problems live at peak-of-peak, so 40% average utilization can coexist with 95% utilization every morning. Plan against peak percentiles, not averages, and fit growth trends on peak traffic rather than mean traffic.

Do not use capacity planning for real-time scaling during an active incident; that belongs to incident triage and mitigation workflows. Capacity planning is the preventive work done before events, using weeks of telemetry history and defined SLOs.

Beyond CPU and memory, check data growth effects on query performance, database connection counts multiplied by new replicas, queue drain time after outages at peak, third-party contractual TPS limits, and cloud account quotas, all of which have ended real traffic events.