Infrastructure Capacity Planning
Infrastructure capacity planning predicts the computing resources a workload needs to meet its performance and reliability targets. It connects expected demand with tested limits so you can avoid both shortages and waste.
itInfrastructure and operations | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Infrastructure Capacity Planning
Infrastructure capacity planning is the discipline of deciding what a system must have ready before demand arrives. It is not, despite the efforts of countless dashboards, a ritual in which a CPU line is stared at until it confesses. The useful question is whether the service can complete the work people bring it while its latency, errors, availability, and allowed degradation remain acceptable.
The first durable idea is the service target. A request rate on its own is only a large number wearing a name badge. Add the behavior that must hold at that rate, and it becomes a boundary you can test. The second is the demand scenario: normal traffic, a peak, a launch, or the traffic left after some defined loss. History helps with ordinary growth, but it is notoriously poor at mentioning the campaign someone already scheduled.
Next comes the tested limit, which is the most valuable number in the room and also the least portable. Apply representative load, watch throughput, latency, errors, queues, and resource limits, then find the highest load that still meets the target. Run a gradual ramp and a sudden spike. Systems have a special talent for behaving politely while you approach them and dramatically when you arrive all at once.
The arithmetic is pleasantly compact. Divide forecast peak demand by the tested capacity of one unit, then round up. The argument begins immediately afterward. A failure policy says what loss the plan must survive: an instance, a zone, a dependency, or something less conveniently named. A bottleneck is the first constraint that prevents more useful work, and it may be a database connection pool or provider quota rather than the application servers everyone has counted with such affection.
Autoscaling can add supply, but it cannot travel back through its own startup time, quota, or dependency limit. When supply cannot arrive in time, queues, throttles, rate limits, load shedding, and selective degradation become the ways to preserve the work that matters most. None is a decorative emergency lever; each needs defined behavior and a test.
Read the Intro for the full loop from targets to provisioning. Use Slides for the relationships and decisions at a glance. Keep the Cheatsheet nearby when writing the record or checking a plan, and use the Practice tab to turn a scenario into a calculation and an action date. The Quiz is where the apparently harmless server count discovers that it has been asked to explain itself.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://sre.google/sre-book/introduction/
Supports
- Capacity planning as an SRE responsibility
- Organic and inorganic demand forecasting
- Forecast horizon beyond provisioning lead time
- Load testing to correlate raw resources with service capacity
- Capacity, demand, software efficiency, provisioning, and cost relationships
- https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/capacity-planning
Supports
- Capacity planning definition and performance-target focus
- Historical data, workload patterns, peak demand, and scenario forecasting
- CPU, memory, storage, network, personnel, application, and service limits
- Bottleneck identification from throughput and response behavior
- Pilots, expert judgment, and external evidence for new workloads
- Autoscaling, quotas, scaling limits, monitoring, and testing
- Underprovisioning and overprovisioning tradeoffs
- https://sre.google/sre-book/service-best-practices/
Supports
- N plus two capacity policy
- Forecast validation against actual demand
- Load testing as evidence for resource-to-capacity ratios
- Launch demand differing from steady-state demand
- Graceful degradation and load shedding during overload
- https://sre.google/sre-book/addressing-cascading-failures/
Supports
- Capacity planning coupled with performance testing
- Capacity calculation from peak load, tested breaking point, and redundancy
- Limits of capacity planning as a cascading-failure defense
- Queue effects, breaking-point testing, and gradual versus impulse load
- Load shedding, retries, and uneven load as overload concerns
- https://sre.google/sre-book/software-engineering-in-sre/
Supports
- Capacity planning as a repeated forecast and allocation cycle
- Location, redundancy, dependency, budget, and priority constraints
- Intent-based requirements and allocation planning
- Resource units in different locations not always interchangeable
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the curated Awesome Site Reliability Engineering list
- https://github.com/dastergon/awesome-sre
Supports
- Discovery of capacity-planning resources and the Awesome SRE Tools list
- https://github.com/SquadcastHub/awesome-sre-tools
Supports
- Discovery of k6 and Gatling as continuous-testing tools
- Discovery of Prometheus as a continuous-monitoring tool
- https://grafana.com/docs/k6/latest/
Supports
- k6 load-test types including average, stress, soak, spike, and breakpoint tests
- API and protocol performance testing
- Test-result exports and dashboard integrations
- https://docs.gatling.io/
Supports
- Gatling as a code-driven load-testing tool
- Workload models, protocol testing, automation, and result analysis
- https://prometheus.io/docs/introduction/overview/
Supports
- Prometheus collection and storage of timestamped metrics
- Dimensional queries, graphing, dashboards, and alerting
- Request, connection, and application measurements used to understand system behavior
- https://aws.amazon.com/builders-library/static-stability-using-availability-zones/
Supports
- Immediate capacity for Availability Zone impairment
- Static stability and the cost of pre-provisioned failure capacity
- https://grafana.com/oss/k6/
Supports
- Grafana k6 open-source and hosted load-testing options
- https://gatling.io/pricing
Supports
- Gatling Community Edition and commercial Enterprise options
- https://jmeter.apache.org/
Supports
- Apache JMeter protocol performance testing and Apache licensing
- https://locust.io/
Supports
- Locust open-source Python load testing and commercial support option
- https://www.datadoghq.com/product/infrastructure-monitoring/
Supports
- Datadog Infrastructure Monitoring product and free-tier availability
