# Capacity Planning Without a Crystal Ball

> Skip the forecast. You need headroom, growth rate, and how long it takes to add capacity.

Source: https://christwentyfour.com/blog/capacity-planning-without-a-crystal-ball

You do not need to predict the future. You need three numbers: current headroom, how fast you use it, and how long it takes to add more.

## Measure headroom in load

Seventy percent utilization does not tell you how much traffic you can take before latency breaks. Systems slow down gradually, then fall off a cliff. Find the knee with a load test.

Two formulas explain the cliff. Little's law says the work in the system equals arrival rate times time in the system:

$$L = \lambda W$$

**Worked example:** **50** requests in flight

At 200 requests a second and 0.25 seconds each, 50 requests are in flight. If latency doubles, so does the number in flight, and so does the memory and connections they hold.

Utilization is arrival rate over service rate:

$$\rho = \frac{\lambda}{\mu}$$

For a simple single-server queue (M/M/1), the average time in the system is:

$$W = \frac{1}{\mu - \lambda}$$

**Worked example:** **50 ms** at 80% utilization · **200 ms** at 95% utilization

Take a server that handles 100 requests a second, so one request takes 10 ms alone. At 80% utilization (\(\lambda = 80\)), \(W = 1/20 = 50\) ms. At 95% (\(\lambda = 95\)), \(W = 1/5 = 200\) ms. Fifteen points more load gave four times the latency, because the denominator \(\mu - \lambda\) shrinks toward zero as \(\rho \to 1\). Real systems are messier, but the shape holds.

**Wait against utilization, one server at 100 requests a second**

Fifteen points more load, from 80% to 95%, takes the average wait from 50 ms to 200 ms.

## A system at capacity has no slack

A retry storm, a slow dependency, a batch job, a traffic spike. Each one needs somewhere to go. Without slack, that becomes a queue, and the queue becomes timeouts. Slack is what lets you survive what you did not plan for.

## Know three things per system

- **Headroom**: how far load can grow, as a multiple of today.
- **Growth rate**: measured over months, not weeks.
- **Lead time**: from noticing a problem to serving traffic on new capacity, manual steps included.

If lead time is longer than the time until you run out, you have a problem now.

## Autoscaling is not a plan

It works inside capacity you already have. It does not fix a database connection cap, a third-party rate limit, or a quota that needs an email. Write down the real ceiling and what sets it.

## Capacity and cost are one conversation

Provisioning for a peak you see twice a year costs you all year. Make that trade on purpose.