Capacity planning is the practice of forecasting how much compute, memory, storage and network capacity a system will need to serve expected demand while meeting its reliability and performance targets. It combines utilization and saturation metrics, demand forecasts, load tests and lead times to decide when and how much to scale.
What is capacity planning?
Capacity planning answers a simple question with a lot of nuance: will the system still meet its targets next week, next quarter and during the next peak, and what has to change for that to be true? It covers compute, memory, storage, network, database connections, queue throughput, license limits and cloud quotas, in short every resource that can run out.
Autoscaling in the cloud has not made capacity planning obsolete. It moved the questions: what are the scaling limits and quotas, how fast does scaling react compared with traffic spikes, which components such as databases do not scale horizontally, and what will the extra capacity cost.
Capacity planning also differs from performance tuning. Tuning makes a component do more with the same resources; capacity planning decides how many resources are needed, where, and by when. Both feed each other, because every efficiency gain changes the forecast.
Why capacity planning matters
- Reliability: resources that approach exhaustion cause rising latency and errors long before they are at 100 %, because queues build up.
- Cost: overprovisioning wastes money, while underprovisioning causes incidents and emergency purchases.
- Lead time: new hardware, reserved instances, quota increases or a database migration take weeks, so they must be planned before they are urgent.
- Business events: launches, campaigns or seasonal peaks need capacity that historical averages do not show.
Key metrics for capacity planning
A good starting point is the USE method: for every resource, look at utilization, saturation and errors. Combine that with demand metrics:
| Category | Examples |
|---|---|
| Demand | Requests per second, active users, messages per second, data ingested per day |
| Utilization | CPU, memory working set, disk usage, network bandwidth, connection pool usage |
| Saturation | Queue depth, CPU throttling, run queue length, consumer lag, wait time for connections |
| Outcome | Latency percentiles and error rate against the SLO |
The most useful number is often the ratio between demand and resource usage, for example CPU seconds per thousand requests. It turns a traffic forecast into a resource forecast and reveals efficiency regressions after releases.
The capacity planning process
- Measure the current state as time series with enough history to see daily, weekly and seasonal patterns.
- Find the limit of each component through load tests: the throughput at which latency or errors violate the SLO, not the point at which the server crashes.
- Forecast demand from trends plus known business events.
- Define headroom: the safety margin for spikes, the failure of a zone or node (N+1) and the time it takes to add capacity.
- Act and review: scale, optimize or re-architect, then compare the forecast with reality and adjust the model.
Repeat the cycle on a fixed cadence, for example monthly for fast-growing services and quarterly for stable ones, and additionally before every known peak. Ownership matters: each service team should know its own limits and forecasts, while a platform or SRE team aggregates them for shared resources such as clusters, databases and network links.
Example: a simple capacity calculation
An illustrative case: load tests show that one instance of an API keeps p99 latency within the SLO up to 400 requests per second. Today's peak is 2,000 requests per second, and the forecast expects 30 % growth over the next six months, so about 2,600 requests per second. The service runs in three zones and must survive the loss of one. Raw need is 2,600 / 400 = 6.5, so 7 instances. To keep serving with one zone lost, the remaining two zones must hold those 7 instances, which means 4 per zone and 12 in total. Little's law (concurrency = arrival rate × time in system) can be used in the same way to size connection pools and worker counts from throughput and latency.
Common mistakes
- Planning on averages instead of peaks and percentiles.
- Targeting very high utilization; latency rises sharply as utilization approaches saturation.
- Ignoring non-scalable components such as a single primary database, a third-party API with rate limits or cloud quotas.
- Treating capacity planning as a yearly spreadsheet exercise instead of a continuous review tied to throughput trends and releases.
How Obseria helps
Obseria keeps metrics for 13 months, so seasonal patterns and year-over-year comparisons are available for forecasting. You can query demand and resource usage with PromQL or SQL, relate them to the golden signals of each service, and use anomaly detection to spot unexpected growth early. Cloud cost management connects capacity decisions to spend.
