Skill — Capacity Planning
When this skill activates
Any task involving capacity modeling, growth forecasting, scaling triggers,
headroom calculation, saturation point analysis, or bottleneck forecasting.
Mandatory actions when this skill is active
Before writing any code
- Measure current utilization across all system components.
- Model growth using historical data and planned launches.
- Identify the first bottleneck (component that saturates first).
During implementation
- Define scaling triggers with thresholds and cooldown periods.
- Implement capacity metrics (utilization, queue depth, latency).
- Configure auto-scaling aligned with the capacity model.
- Maintain 30-40% headroom above expected peak.
After implementation
- Validate model with load testing at projected future load.
- Set alerts for approaching saturation (70%, 85%, 95%).
- Schedule quarterly capacity review to recalibrate.
Methodology
- Measure: baseline CPU, memory, disk IO, network, app-level metrics (p50/p95/p99).
- Model: organic growth + step functions (launches) + seasonal patterns.
- Identify: map each component to its saturation point, find the first bottleneck.
- Plan: define scaling triggers, budget infrastructure, document runbook.
Growth Forecasting
projected_month_N = current * (1 + growth_rate)^N + planned_launch_impact
- Historical trend: last 3-6 months. Seasonal patterns: daily/weekly/yearly peaks.
- Peak-to-average ratio determines required vs baseline capacity.
Headroom Calculation
Required Capacity = Expected Peak / (1 - headroom_fraction)
Example: 700 RPS peak, 30% headroom → 700/0.70 = 1000 RPS provisioned
- Fast auto-scaling (<2 min): 20-30% headroom.
- Slow scaling (>10 min): 40-50% headroom.
- No auto-scaling: 50%+ or accept degradation risk.
Saturation Point
- The load at which p99 latency exceeds SLA or error rate exceeds threshold.
- Find via incremental load test (ramp 0 → 2x peak), plot load vs latency.
- The "knee" where the curve bends sharply = saturation. Operate well below it.
Scaling Triggers
| Metric |
Threshold |
Action |
| CPU > 70% for 5 min |
Scale out application tier |
|
| Memory > 80% |
Scale up or out |
|
| Queue depth > 1000 for 3 min |
Add consumers |
|
| p99 > 500ms for 2 min |
Scale application |
|
| Error rate > 1% for 1 min |
Investigate + possibly scale |
|
- Cooldown after scale-out: 5 min. After scale-in: 15 min (prevent flapping).
- Predictive: pre-scale before known peaks (Monday AM, campaign launch).
Bottleneck Forecasting
| Component |
Current Util |
Saturation |
Time to Sat |
| API servers |
45% |
80% |
4 months |
| Database |
62% |
75% |
6 weeks |
| Cache |
30% |
85% |
8 months |
Focus on shortest time-to-saturation first.
Self-check before task completion
1---2name: capacity-planning3description: Skill — Capacity Planning4---56# Skill — Capacity Planning78## When this skill activates9Any task involving capacity modeling, growth forecasting, scaling triggers,10headroom calculation, saturation point analysis, or bottleneck forecasting.1112## Mandatory actions when this skill is active1314### Before writing any code151. Measure current utilization across all system components.162. Model growth using historical data and planned launches.173. Identify the first bottleneck (component that saturates first).1819### During implementation20- Define scaling triggers with thresholds and cooldown periods.21- Implement capacity metrics (utilization, queue depth, latency).22- Configure auto-scaling aligned with the capacity model.23- Maintain 30-40% headroom above expected peak.2425### After implementation26- Validate model with load testing at projected future load.27- Set alerts for approaching saturation (70%, 85%, 95%).28- Schedule quarterly capacity review to recalibrate.2930## Methodology31321. **Measure**: baseline CPU, memory, disk IO, network, app-level metrics (p50/p95/p99).332. **Model**: organic growth + step functions (launches) + seasonal patterns.343. **Identify**: map each component to its saturation point, find the first bottleneck.354. **Plan**: define scaling triggers, budget infrastructure, document runbook.3637## Growth Forecasting3839```40projected_month_N = current * (1 + growth_rate)^N + planned_launch_impact41```4243- Historical trend: last 3-6 months. Seasonal patterns: daily/weekly/yearly peaks.44- Peak-to-average ratio determines required vs baseline capacity.4546## Headroom Calculation4748```49Required Capacity = Expected Peak / (1 - headroom_fraction)50Example: 700 RPS peak, 30% headroom → 700/0.70 = 1000 RPS provisioned51```5253- Fast auto-scaling (<2 min): 20-30% headroom.54- Slow scaling (>10 min): 40-50% headroom.55- No auto-scaling: 50%+ or accept degradation risk.5657## Saturation Point58- The load at which p99 latency exceeds SLA or error rate exceeds threshold.59- Find via incremental load test (ramp 0 → 2x peak), plot load vs latency.60- The "knee" where the curve bends sharply = saturation. Operate well below it.6162## Scaling Triggers6364| Metric | Threshold | Action |65|--------|-----------|--------|66| CPU > 70% for 5 min | Scale out application tier | |67| Memory > 80% | Scale up or out | |68| Queue depth > 1000 for 3 min | Add consumers | |69| p99 > 500ms for 2 min | Scale application | |70| Error rate > 1% for 1 min | Investigate + possibly scale | |7172- Cooldown after scale-out: 5 min. After scale-in: 15 min (prevent flapping).73- Predictive: pre-scale before known peaks (Monday AM, campaign launch).7475## Bottleneck Forecasting7677| Component | Current Util | Saturation | Time to Sat |78|-----------|-------------|------------|-------------|79| API servers | 45% | 80% | 4 months |80| Database | 62% | 75% | 6 weeks |81| Cache | 30% | 85% | 8 months |8283Focus on shortest time-to-saturation first.8485## Self-check before task completion8687- [ ] Is current utilization measured across all critical components?88- [ ] Is growth model based on historical data plus planned launches?89- [ ] Is the first bottleneck identified with time-to-saturation?90- [ ] Are scaling triggers defined with thresholds and cooldowns?91- [ ] Is 30-40% headroom maintained above expected peak?92- [ ] Has the model been validated with load testing?93- [ ] Are alerts configured for approaching saturation?
sairam0424