kienbui1995 Capacity Planning
When to Use
When you need to ensure infrastructure can handle current load, planned growth, or traffic spikes without over-provisioning.
Core Jobs
1. Measure Current Baselines
For each service, measure:
- Throughput: requests/sec at P50, P95 traffic
- Latency: P50, P95, P99 response time
- Resource utilization: CPU%, memory%, disk I/O, network
- Saturation point: at what RPS does P99 latency degrade?
- Headroom: current utilization vs saturation point
2. Model Growth
- Historical traffic growth rate (last 3–6 months)
- Planned initiatives that will change load (new features, marketing campaigns)
- Seasonality (peak hours, days, months)
- Project 3 months and 12 months forward
3. Calculate Required Capacity
Required instances = (Peak RPS × Avg latency) / (1000ms × CPU cores × target utilization)
Target utilization: 60–70% CPU at peak (leave headroom for spikes and rolling deploys)
4. Make Scaling Decisions
Options:
- Vertical scaling: larger instances (fast, expensive, limits)
- Horizontal scaling: more instances (preferred, needs stateless design)
- Auto-scaling: HPA on Kubernetes, ASGs on AWS (set based on CPU or custom metric)
- Caching: reduce load on DB/API (often 10x more cost-effective than scaling)
5. Plan for Spikes
- Load test at 2x expected peak before major launches
- Pre-scale before known events (product launches, marketing campaigns)
- Circuit breakers to shed load gracefully
Key Outputs
- Current baseline measurements
- 3-month and 12-month capacity projections
- Scaling recommendation with cost estimate
- Load test results
Anti-Patterns
- Planning based on average load, not peak
- No load testing before major launches
- Scaling CPU-bound services horizontally without profiling
- Over-provisioning permanently for spikes that last hours