What is Capacity Planning and How Do You Do It?
Learn what capacity planning is, how to forecast load, benchmark instances, and size infrastructure with headroom for spikes.
Expected Interview Answer
Capacity planning is the process of estimating the compute, storage, and network resources a system needs to handle projected load with acceptable performance and headroom, so you provision ahead of demand instead of reacting to outages.
It starts by translating a business projection (users, requests, data growth) into concrete numbers: queries per second, storage growth per day, and peak-to-average traffic ratios. From there you benchmark a single instance to find its safe throughput ceiling (usually well below its theoretical max, leaving headroom for spikes and failover), then divide projected peak load by that ceiling to get the required instance count. Good capacity plans build in margin for traffic spikes, seasonal peaks, and the loss of at least one availability zone, and they get revisited on a cadence as real traffic data replaces projections. Skipping this step is how teams get paged at 2 a.m. when a launch or a viral moment doubles traffic overnight.
- Prevents outages caused by underprovisioned systems during launches or spikes
- Avoids overspending on idle headroom by sizing to actual projected load
- Surfaces bottlenecks (CPU, memory, disk I/O, network) before they hit production
- Gives finance and engineering a shared, defensible number for budgeting infrastructure
AI Mentor Explanation
Capacity planning is like a stadium curator deciding how many turnstiles to open for a World Cup final versus a routine domestic match. The curator studies past attendance data, estimates the peak arrival rate in the hour before the toss, and divides that by how many fans one turnstile can process per minute to decide staffing. They also add extra turnstiles beyond the bare minimum in case a star player draws an unexpected surge. Skipping this estimation is exactly how stadiums end up with dangerous crushes at the gates.
Step-by-Step Explanation
Step 1
Forecast the business projection
Translate expected users, requests, or data growth into concrete traffic and storage numbers over a time horizon.
Step 2
Benchmark a single unit
Load test one instance or shard to find its safe sustained throughput ceiling, well below its theoretical peak.
Step 3
Compute required capacity
Divide projected peak load by the per-unit ceiling, then add margin for spikes, failover, and at least one lost availability zone.
Step 4
Monitor and revisit
Track real usage against the plan on a regular cadence and adjust projections as actual traffic data replaces estimates.
What Interviewer Expects
- Frames capacity planning as forecast-to-provisioning, not a single guessed number
- Mentions benchmarking real hardware/instances rather than trusting spec sheets alone
- Builds in headroom for peak-to-average ratios and failure scenarios (lost AZ, node failure)
- Treats the plan as a living process revisited with real telemetry, not a one-time exercise
Common Mistakes
- Sizing to average load instead of peak load
- Trusting vendor theoretical maximums instead of benchmarking real workloads
- Forgetting to reserve headroom for failover when a node or zone goes down
- Treating capacity planning as a one-time task instead of an ongoing feedback loop
Best Answer (HR Friendly)
“Capacity planning is figuring out ahead of time how much computing power, storage, and bandwidth a system will need so it does not fall over when real users show up. You start from a business forecast, test how much one server or unit can actually handle, then work out how many you need with some safety margin built in, and keep revisiting that number as real traffic comes in.”
Code Example
def required_instances(
projected_peak_rps: float,
safe_rps_per_instance: float,
headroom_factor: float = 1.3,
min_for_failover: int = 2,
) -> int:
"""Return the number of instances needed to safely serve peak load.
headroom_factor adds margin for traffic spikes above the forecast.
min_for_failover ensures the fleet survives losing at least one node.
"""
raw_needed = (projected_peak_rps * headroom_factor) / safe_rps_per_instance
import math
return max(math.ceil(raw_needed), min_for_failover)
# Example: forecast 4,500 requests/sec at peak, one instance
# safely sustains 600 requests/sec under load testing.
instances = required_instances(
projected_peak_rps=4500,
safe_rps_per_instance=600,
)
print(instances) # 10 instances, including headroom and failover floorFollow-up Questions
- How would you determine the safe throughput ceiling for a single instance under load testing?
- What peak-to-average traffic ratio would you assume for a launch day versus a steady-state service?
- How does capacity planning change for stateful services like databases versus stateless API servers?
- How would you revise a capacity plan after observing real production traffic for a month?
MCQ Practice
1. What should capacity planning primarily size a system for?
Systems must survive peak, not average, load — sizing to averages causes outages during spikes.
2. Why should you benchmark a single instance rather than trust vendor specs?
Theoretical maximums assume ideal conditions; real safe throughput is typically much lower under realistic, sustained load.
3. What is a key reason to add headroom for a lost availability zone?
Capacity plans that assume every zone stays healthy fail exactly when a zone outage compounds with peak traffic.
Flash Cards
What is capacity planning? — Estimating the resources a system needs to handle projected load with acceptable performance and headroom.
Why size for peak, not average? — Average sizing leaves no room for spikes, causing outages exactly when demand is highest.
Why benchmark instead of trust specs? — Real sustained throughput under load is usually well below vendor theoretical maximums.
Why revisit the plan regularly? — Real traffic data is more accurate than projections, so plans should adapt as actual usage comes in.