Interactive design lab

Capacity Planning Control Room

What is capacity planning?

Capacity planning turns a demand forecast into a tested operating envelope: retained data, peak traffic, provisioned resources, required reserve, and the conditions that will exhaust them.

Step 1

Model

Model user growth and retention separately from request traffic, measured instance throughput, reserve, and editable cost assumptions.

Step 2

Observe

See the formulas, uncertainty band, replicated footprint, serving headroom, first bottleneck, and minimum fleet size behind the recommendation.

Step 3

Challenge

Compare the planned peak with a launch spike, retention shock, and one-zone loss. A plan is credible only when its most important failure still has an explicit response.

Capacity control room

Plan for demand, then break the plan

Forecast retained data and peak traffic, size against tested limits, and inject a failure before the real launch does.

Scenario status

Reserve intact

Challenge the envelope

Operational scenario

Scenario factors affect demand, retention, or surviving capacity. They do not silently alter your inputs.

Loop 1

Growth and storage

Change the audience or retention contract and watch the forecast and replicated footprint move.

Current usersusersAnnual growth35%Compounded across the selected horizon.

Planning horizon

New data per userKB / dayLogical data created before replication.Retention90 daysServing-store retention before archival or deletion.

Replication factor

Forecast uncertainty20%Visible planning band, not fake precision.

Loop 2

Traffic and headroom

Tie peak demand to measured per-instance throughput and an explicit reserve target.

Active users at once12%Concurrent active share of projected users.Requests per active userrequests / min

Peak over average

Average responseKBUsed to estimate outbound network demand.Tested instance throughputRPS / instanceUse a sustained load-test result, not a vendor maximum.Provisioned instancesinstancesRequired reserve30%Unused tested capacity kept for failures and scaling lag.

Forecast outcome

1.8M users at month 24

Shaded range is the configured +/-20% planning band.

users = current x (1 + annual growth)^{months / 12}

Retained footprint

88.57 TB across 3 copies

90 effective retained days under planned peak.

users x daily KB x retained days x replicas / 1B

Raw 29.52 TB

Replica overhead 59.05 TB

Logical data is shown separately from availability copies.1.8M users x 180 KB/day

Serving envelope

87.5K scenario RPS through 56 surviving instances

Demand stays inside the tested operating envelope with reserve intact.

37.5% headroom

Demand 87.5K RPS

0Reserve starts at 98K RPSTested 140K RPS

Average demand

29.2K RPS

218.7K concurrently active users

Scenario peak

87.5K RPS

16.8K Mbps outbound at peak

Required fleet

50 nodes

At 30% reserve and tested throughput

First constraint

Fleet headroom

Keep the load test, autoscaling threshold, and observed saturation metric aligned with this envelope.

Projected workload

87.5K planned peak RPS

Planned peak

87.5K RPS presented

Serving result

Reserve intact

Illustrative run rate

$157,325 per month

Rates are editable planning assumptions, not a vendor quote. Peak challenge duration is not added to the monthly egress estimate.

Compute

$10,080

56 provisioned x $180

Replicated storage

$2,126

88.57 TB x $24

Average egress

$145,119

1.8M GB x $0.08

Traffic formula: users x active share x requests/min / 60 x peak factors.

Fleet formula: ceil(scenario RPS / tested node RPS / (1 - reserve)).

Excluded: databases, queues, support, taxes, discounts, and workload-specific amplification.

No quiz questions available

Could not load questions file