Capacity Planning Calculator

Capacity planning is the process of determining the computational resources (CPU, memory, pods/instances) needed to handle projected traffic — both current and future. Without it, services either under-provision (leading to performance degradation and outages) or over-provision (wasting significant cloud budget). Good capacity planning combines traffic forecasts, per-request resource profiling, and safety margins.

Use profiling tools: for web services, instrument with OpenTelemetry or language-specific profilers (pprof for Go, py-spy for Python, async_profiler for Java). Run a controlled load test and measure total CPU seconds consumed divided by request count. Alternatively, look at CPU utilization from your APM at a known RPS and divide: CPU% × cores / RPS = CPU seconds per request.

Target 60-70% CPU utilization under sustained normal load. This leaves headroom for: traffic spikes (20-30% above normal), garbage collection pauses, OS overhead, and auto-scaling reaction time. Running above 80% CPU consistently is dangerous — latency degrades non-linearly past 70-80% utilization due to queuing theory (Little's Law).

Pod memory requests should match the average working set; limits should be 1.5–2x requests to handle spikes. Profile memory usage under load: baseline idle memory + (requests in flight × memory per request) + framework overhead. Always set both requests and limits — pods without limits can starve neighbors. Use VPA (Vertical Pod Autoscaler) or regular profiling to tune over time.

Compound monthly growth compounds rapidly. 10% monthly growth = 214% growth over 12 months (3.14x). 20% monthly = 792% (8.9x). This means a service handling 1,000 RPS today needs to handle 3,140–8,900 RPS in a year. Always plan hardware procurement and architectural changes 3-6 months ahead of when you expect to need them, accounting for lead times.