Capacity Planning Workshop

Capacity planning is the discipline of answering one question before it becomes an outage: how much load can the system carry, and when will we run out? A short, structured workshop beats a spreadsheet created in isolation because it surfaces assumptions from product, operations and engineering at the same table. This guide gives you a repeatable format that fits in half a day.

Learning goals

Translate business forecasts into request rates and data volumes
Identify the bottleneck resource for each major component
Define headroom targets and scaling triggers the team agrees on
Produce a one page capacity plan you can revisit each quarter

Step-by-step procedure

Gather inputs a week ahead: traffic graphs for the last six months, growth forecasts from product, and the list of planned launches or campaigns.
Draw the request path on a whiteboard from edge to datastore. Mark every component that holds state or has a fixed pool size.
For each component, name its limiting resource: CPU, memory, connections, disk throughput, or a third party rate limit.
Measure or estimate the cost per request on that resource. Use load test data where you have it and label guesses clearly.
Project demand at three horizons: 3, 6 and 12 months. Use a base, a high and a spike scenario.
Set headroom targets. A common rule is to run at no more than 60 percent of the tested limit at peak, leaving room for failure of one node.
Convert targets into scaling triggers, such as add a replica at 55 percent sustained CPU, and assign an owner for each.
Record open questions and schedule a review date.

Worked example

Suppose a checkout service handles 120 requests per second at peak. Product expects 40 percent growth in six months plus a holiday spike of three times normal traffic. A load test shows one instance sustains 50 requests per second before latency degrades. Base demand at six months is 168 requests per second. The spike scenario is 504. With a 60 percent headroom rule, each instance contributes 30 requests per second, so the base case needs six instances and the spike case seventeen. The database is the real constraint: each request issues four queries and the primary tops out near 2,000 queries per second, which caps the system near 500 requests per second. The workshop therefore decides to add a read replica before the holiday period and to cache the product lookup.

Exercises and templates

Run the workshop on one service you own and produce the one page plan.
Find the component whose limit you know least about and design a test to measure it.
Write three scaling triggers with an owner and an expected response time for each.

Template:

Component | Limit | Cost per request | Peak demand | Headroom | Trigger
Checkout API | 50 rps per node | 1 CPU unit | 168 rps | 40 percent | CPU 55 percent for 10 min

Common pitfalls

Planning from average load instead of peak, which hides the hours that actually cause incidents.
Ignoring downstream dependencies such as payment providers whose rate limits you do not control.
Treating the plan as a document rather than a living set of triggers wired into alerts.
Skipping cost: every extra replica has a price, so record the monthly cost of each scaling step and let finance see it.

Follow-up and continuous improvement

After the workshop, publish the plan where on call engineers can find it, and link each trigger to an alert. Revisit the numbers after every major launch and after any incident caused by saturation. Over time, compare forecasts with actual traffic. If you were off by more than twenty percent, discuss why: was it a product assumption, a measurement error, or a change in user behaviour? That feedback loop is what makes later workshops faster and more accurate.

Key takeaways

Plan from the bottleneck, not from the average component
Always state assumptions and label estimates versus measurements
Headroom must cover the loss of a node, not just growth
Review the plan on a fixed schedule so it never goes stale