Capacity Planning Basics

Your product gets featured, traffic triples, and your servers — fine yesterday — fall over right when it matters most. That's a capacity failure, and it's heartbreaking because it usually strikes during success. Capacity planning is the unglamorous discipline that makes sure you have the headroom before you need it.

What capacity planning is

Capacity planning is forecasting how much load your systems will face and making sure you have enough resources to handle it — comfortably, with margin. It's about answering "can we handle what's coming?" before it arrives, rather than discovering the answer the hard way.

The simple loop

At its core, capacity planning is three steps you repeat:

Step	What you do
Measure	Know your current load and resource usage
Forecast	Project growth and expected spikes
Provision	Add headroom ahead of need

1. Measure current load

You can't plan without a baseline. Track the resources that constrain you — CPU, memory, disk, connections, requests per second — and know how much headroom you have today. The most important question: at what point do things start to degrade?

2. Forecast demand

Project forward, accounting for both:

Steady growth — your normal week-over-week trend.
Known spikes — launches, campaigns, seasonal peaks (Black Friday is the classic), press coverage.

A launch that 5×'s your traffic needs planning before the launch, not during.

3. Provision with margin

Add capacity ahead of the forecast, with a buffer. Don't provision for today's peak — provision for the peak you expect plus a safety margin, because forecasts are never exact.

The golden rule: provision before you need it, not when you're already on fire. Adding capacity takes time — spinning up infrastructure, warming caches, scaling databases. If you wait until you're saturated, you're adding capacity during the outage, which is the worst time. Headroom is cheaper than downtime.

Modern capacity: autoscaling helps, but isn't magic

Autoscaling automatically adds resources as load rises — a huge help. But it's not a free pass:

It has limits and lag — scaling takes time, and a sudden spike can outrun it.
Some things don't autoscale easily (databases, third-party rate limits).
For a known big event, pre-scale (warm up) rather than relying on reactive autoscaling alone.

Autoscaling handles the gradual; planning handles the predictable spikes.

Capacity failures show up as...

When you run out of capacity, users see 503s, timeouts (504), and slow pages. Those are the same symptoms as other outages, which is why monitoring matters: it tells you when you're approaching the edge.

A monitoring connection

Capacity planning lives on data. Monitoring your resource utilisation and response times over time gives you the trends to forecast from — and predictive alerting ("at this rate, you'll hit the limit in N hours") buys you the lead time to provision before you saturate.

The bottom line

	In one line
What	Ensuring you have enough resources for what's coming.
Loop	Measure → forecast → provision (with margin).
Rule	Add headroom before you need it, not during the outage.
Autoscaling	Helps, but has lag/limits — pre-scale for known spikes.

Capacity planning is how success stays a celebration instead of becoming an outage. Measure your headroom, forecast your spikes, and provision ahead — so your big day is your best day, not your worst.