Capacity planning is the process of ensuring infrastructure can handle expected demand, failures and growth without unnecessary cost or avoidable performance problems.
1) Measure demand, not just installed capacity
Installed capacity describes what a system could theoretically provide. Useful planning begins with actual utilization, peak demand, growth rate and the relationship between workload and user experience.
Average utilization can hide short peaks. Percentiles, queue depth, latency and saturation indicators often provide a better picture.
2) Headroom
Headroom is unused capacity reserved for growth, bursts, maintenance and failure. The correct margin depends on how quickly capacity can be added and how serious saturation would be.
Infrastructure with a six-month procurement lead time needs earlier action than a cloud resource that can be expanded in minutes.
3) Capacity is constrained by the bottleneck
A service may have spare CPU but be limited by memory, storage latency, database connections, network throughput or a third-party API. Planning must cover the end-to-end service, not one component.
Bottlenecks can move after an upgrade, so the system should be re-measured after changes.
4) Plan for degraded states
A two-node cluster may look comfortable during normal operation but overload when one node is unavailable. Capacity reviews should calculate utilization with expected failures and maintenance conditions.
The same principle applies to power paths, network links, storage controllers and cloud zones.
5) Forecasting methods
- Trend historical demand by month or quarter
- Model known projects and customer changes separately
- Use best, expected and high-growth scenarios
- Include seasonal peaks and batch workloads
- Track procurement and deployment lead times
6) Define action thresholds
A capacity plan should specify when investigation, budgeting and expansion begin. Thresholds should leave enough time to act before service quality is affected.
The threshold is not always a percentage. It may be a latency target, queue size, recovery margin or remaining support life.
7) A useful review record
- Current capacity and peak utilization
- Forecast period and assumptions
- Failure-state utilization
- Known bottlenecks
- Expansion options and lead time
- Decision owner and next review date
Operational review questions
Use these questions to connect the concept to a real service or environment:
- Which user outcomes and service objectives are measured?
- Are alerts actionable and tied to an owner?
- Can incidents be traced across shared dependencies?
- How long is useful operational evidence retained?
- How are noisy alerts and blind spots corrected?
Related guides
What Observability Means in Modern Infrastructure
A detailed, plain-language explanation of observability in modern infrastructure, including metrics, logs, traces, and how systems are monitored and understood in real-world operations.
OperationsMonitoring vs Observability Explained
A plain-language comparison of monitoring and observability, including alerts, metrics, logs, traces, service context and operational decision-making.
OperationsInfrastructure Lifecycle and Technical Debt
A guide to support life, warranties, patchability, replacement planning, technical debt and the operational risks of ageing infrastructure.
Network & DeliveryAnycast Routing Explained — Why CDNs and DNS Work So Fast
A plain-language explanation of anycast routing and why it allows DNS providers, CDNs, and global platforms to deliver traffic from the nearest location.