Capacity Planning

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

1. Current Load Profile

   • Peak throughput (req/sec, transactions/sec)
   • Concurrent users (current and realistic peak)
   • Data volume (stored data, growth rate per month)
   • Data retention policy (how long kept)
   • Backup/archival needs

2. Growth Projections

   • User growth forecast (conservative, realistic, aggressive)
   • Data growth forecast (documents, transactions, logs)
   • Seasonality (peaks in certain months?)
   • Planned feature launches (will they increase load?)
   • Geographic expansion (multi-region needs?)

3. Performance Requirements

   • Latency targets (p50, p95, p99)
   • Throughput targets (concurrent users, req/sec)
   • Availability SLA (uptime %, downtime tolerance)
   • Data consistency requirements (strong vs. eventual)

4. Resource Consumption Model

   • CPU per request (profile via load test)
   • Memory per request (session size, cache needs)
   • Storage per record (database, logs, backups)
   • Network per request (payload size, bandwidth)
   • Database connections (pool size per req/sec)

5. Cost Model

   • Compute costs (servers, containers, serverless)
   • Database costs (managed service, licensing, backups)
   • Network costs (ingress/egress, CDN)
   • Storage costs (primary, backup, archive)
   • Operational costs (monitoring, support, licenses)

Output Format

Capacity Roadmap

Current State (as of [date])

Growth Projections (3-year horizon)

Bottleneck Analysis

At each milestone, what will become the constraint?

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

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

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