| name | capacity-planning |
| description | Forecasts infrastructure and resource needs based on projected growth. Calculates server count, database sizing, network bandwidth, and cost projections. Outputs capacity roadmap with spending milestones. |
| allowed-tools | Write |
| effort | medium |
Capacity Planning
When to activate
After solution architecture is approved and before infrastructure provisioning. Triggered by: known growth trajectory, customer SLA requirements, or periodic review (quarterly). Essential before year-end planning or major feature launches. Run whenever user projections or load profile change significantly.
When NOT to use
Not for existing systems in steady state (use monitoring and alerting instead). Not without load testing data (estimate conservatively if missing). Not for small POCs that will be rebuilt. Not if you have <3 months of production data (too early to extrapolate).
Planning Checklist
-
Current Load Profile
-
Growth Projections
-
Performance Requirements
-
Resource Consumption Model
-
Cost Model
Output Format
Capacity Roadmap
Current State (as of [date])
| Metric | Value |
|---|
| Daily Active Users | 10,000 |
| Peak Throughput | 500 req/sec |
| Stored Data | 500 GB |
| Concurrent Connections | 5,000 |
| API Latency (p99) | 200 ms |
| Database Size | 250 GB |
Growth Projections (3-year horizon)
| Period | Users | Throughput (req/sec) | Stored Data | Infrastructure |
|---|
| Today (M0) | 10K | 500 | 500 GB | 4x app servers, 1x db |
| 6 months (M6) | 25K | 1,200 | 1.2 TB | 8x app servers, 1x db (scaled) |
| 1 year (M12) | 50K | 2,500 | 2.5 TB | 16x app servers, 2x db (replica) |
| 2 years (M24) | 150K | 7,500 | 7 TB | 32x app servers, 4x db (sharded) |
| 3 years (M36) | 300K | 15,000 | 15 TB | 64x app servers, 8x db (distributed) |
Bottleneck Analysis
At each milestone, what will become the constraint?
| Milestone | Bottleneck | Mitigation | Cost Impact |
|---|
| M0→M6 | Database connections | Add connection pooling | +$2K/mo |
| M6→M12 | Compute (CPU on app servers) | Add load balancer, scale out | +$5K/mo |
| M12→M24 | Database query performance | Sharding, replication | +$10K/mo |
| M24→M36 | Network bandwidth | Multi-region, CDN | +$15K/mo |
Server Sizing (per component)
Application Servers
- Current: 4x [size] instances
- M6: 8x [size] instances
- M12: 16x [size] instances
Reasoning: Each server handles ~125 req/sec. At M12 (2,500 req/sec), need 20 servers (over-provisioned by 1.25x for redundancy).
Database
- Current: 1x PostgreSQL [size], 500 GB storage
- M6: 1x PostgreSQL (scaled up), 1.2 TB storage
- M12: 1x primary + 1x replica, 2.5 TB storage
- M24: Sharded (3 shards), 7 TB storage
Reasoning: Single server can handle ~5K req/sec if well-tuned. At M24 (7.5K req/sec), sharding is required to maintain <100ms latency.
Cache Layer (Redis or Memcached)
- Current: 1x Redis [size], 50 GB heap
- M12: 1x Redis (scaled up), 200 GB heap
- M24: Redis cluster (3 nodes), 500 GB total
CDN & Static Serving
- Current: CloudFront, 10 GB/month bandwidth
- M12: CloudFront, 50 GB/month bandwidth
- M24: Multi-region edge, 200 GB/month bandwidth
Cost Projections
| Period | Compute | Database | Network | Storage | Monitoring | Total/Month |
|---|
| M0 | $4K | $2K | $500 | $1K | $500 | $8K |
| M6 | $8K | $4K | $1K | $2K | $1K | $16K |
| M12 | $16K | $8K | $2K | $4K | $2K | $32K |
| M24 | $32K | $16K | $5K | $8K | $4K | $65K |
| M36 | $64K | $32K | $10K | $15K | $8K | $129K |
Cost per User (unit economics)
- M0: $0.80/user/month
- M12: $0.64/user/month
- M24: $0.43/user/month
(Cost decreases with scale due to spreading fixed costs and improving efficiency.)
Contingency Plans
If Growth Exceeds Projections (2x faster):
- Implement aggressive caching (database queries halved)
- Move non-critical services to async queues
- Fast-track sharding implementation
- Consider serverless for traffic spikes
If Growth Stalls:
- Defer sharding/multi-region (save ~$30K/mo)
- Right-size instances (move from large to medium)
- Consolidate underutilized services
- Reduce monitoring/alerting complexity
Optimization Opportunities
| Opportunity | Current Cost | Optimized Cost | Savings | Implementation |
|---|
| Database indexing | $8K | $6K | $2K/mo | Q3 |
| Query optimization | $8K | $6K | $2K/mo | Q3 |
| Connection pooling | $2K | $1K | $1K/mo | Q2 |
| Compression (API responses) | $1K | $0.5K | $0.5K/mo | Q2 |
| Aggressive caching | $2K | $1K | $1K/mo | Q4 |
Scaling Strategy by Component
Vertical Scaling (bigger servers)
- Pros: Simple, less operational overhead
- Cons: Limited ceiling, expensive, eventual downtime for upgrades
- Best for: Small teams, low traffic, early stage
Horizontal Scaling (more servers)
- Pros: Unlimited, resilient, cost-efficient at scale
- Cons: More complex, requires load balancing, stateless design
- Best for: High traffic, growth trajectory, distributed systems
Recommendation: Start vertical (M0–M6), transition to horizontal after M6.
Monitoring & Metrics (for continuous capacity management)
Track weekly:
- Actual vs. projected user growth
- Actual vs. projected load (req/sec, data volume)
- Resource utilization (CPU, memory, disk, network)
- Cost actuals vs. budget
Capacity review quarterly:
- Update growth projections based on new data
- Adjust scaling timeline if needed
- Identify and implement optimizations
- Report to finance on cost efficiency
