plan-application-capacity

Plan application capacity

Read composition guidance for optional expertise, fallback and scope.

Start from demand and service behavior

Identify critical journeys, expected sustained and peak demand, growth, seasonal/burst behavior and acceptable latency.

• Use measured traffic/service times and resource profiles where available; distinguish observations, forecasts and assumptions.
• Inspect tail latency, queues, saturation, throttling, memory peaks and database limits instead of sizing from average CPU alone.
• No telemetry means an estimate requiring validation, not an invented measurement.

Translate demand into simultaneous work along the journey. Relate arrival rate and time in the system to in-flight work with clear units and assumptions, then account for fan-out, retries and operations that hold resources while waiting. Long-running AI/audio work and slow providers can occupy concurrency even when local CPU usage is low. Steady-state queueing estimates do not describe overload or bursts automatically.

Decide where the application stops admitting more work, where it queues work, and what it tells the caller when a bound is reached. Check how long queued work can remain useful and how recovery drains it. Increasing parallelism helps only while the required downstream resources can serve it; otherwise it can increase waiting and failure.

Design a coherent scaling path

Inspect the entire request path: worker/process counts, per-process connection pools, database connection/IO limits, caches, queues, storage and third-party quotas. Adding replicas can multiply database connections and exhaust a shared dependency. Prefer measured query/index improvements, batching, payload reduction and useful caching with explicit freshness/invalidation rules before expanding infrastructure blindly.

Compare the relevant demand conditions:

Scenario	Account for
Normal	Sustained expected demand.
Peak	Expected peak or burst behavior.
Degraded	The failure the application is expected to tolerate.