Capacity planning and demand forecasting is the discipline of predicting how much load a system will face and provisioning just enough compute, storage, and network resources to serve it reliably, sitting squarely inside site reliability engineering alongside monitoring and incident response. It exists because both ends of the sizing problem are costly: too little capacity and a system falls over the moment traffic spikes, taking availability and revenue with it; too much and the organization burns money on idle headroom that never gets used. The non-obvious part is that most systems don't fail by running out of raw resources gradually β they fail suddenly, because queueing latency is nonlinear near saturation: a service running comfortably at 60% utilization can look nearly identical to one at 85%, right up until a small traffic bump pushes it past the knee of the curve and response times explode. Good capacity planning treats forecasting, load testing, autoscaling, and cost as one connected feedback loop rather than four separate jobs, and revisits that loop on a fixed cadence instead of only after an outage forces the question.
What This Cheat Sheet Covers
This topic spans 14 focused tables and 95 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Core Concepts and Vocabulary
These are the terms that show up in every capacity conversation; getting them precise matters because "utilization" and "saturation" are often used loosely but describe genuinely different failure modes.
| Concept | Example | Description |
|---|---|---|
A checkout service rated at 5,000 req/s | The maximum sustainable load a system can serve while still meeting its latency and error targets. | |
Predicting Black Friday will bring 3x normal order volume | Estimating future load ahead of time so capacity can be provisioned before it's actually needed. | |
Running at 40% CPU leaves 60% headroom for a spike | The gap between current utilization and the point where performance starts to degrade. | |
CPU utilization: 72% | The fraction of a resource's capacity currently in use, usually expressed as a percentage. | |
A run-queue length of 4 on a 4-core box | How much extra work a resource has queued that it can't service immediately; degrades performance before 100% utilization is reached. | |
Throughput | 12,400 requests/sec sustained | The rate of work a system actually completes, as opposed to what arrives at it. |