Capacity Plan: [Service or platform name] [Planning period]

Complete capacity plan for one or more production services: demand forecast, current utilisation, headroom policy, resource models, bottlenecks, scaling plan, procurement, cost and risks. Based on common site reliability engineering practice. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Summary
2. Services in scope
3. Demand forecast
4. Current utilisation
5. Headroom policy
6. Resource models per tier
7. Bottleneck analysis
8. Scaling plan
9. Procurement and lead times
10. Cost projection
11. Risks and assumptions
12. Review cadence and accuracy tracking
13. Appendices

1. Summary

[Summarise in four to six sentences. Example: "Peak request rate is forecast to grow from 4,200 to 7,500 requests per second by the end of Q2. At current efficiency the database tier exhausts its CPU headroom in week 14. We propose moving to a larger instance class in week 10 and adding two read replicas, at an incremental cost of [amount] per month. All other tiers have headroom until at least Q3."]

1.1 Key decisions requested

2. Services in scope

Out of scope: [list services excluded and the reason, for example "batch reporting cluster, covered by the data platform plan"].

3. Demand forecast

3.1 Baseline demand

3.2 Growth model

Organic growth is modelled as compound growth per period:

where $D_0$ is baseline peak demand, $g$ is growth per period and $t$ is the number of periods. Example: with $D_0 = 4{,}200$ req/s and $g = 0.05$ per month, demand after 12 months is $4{,}200 \times 1.05^{12} \approx 7{,}540$ req/s.

Known events are added as multiplicative uplifts on the affected periods:

where $u_e$ is the expected uplift of event $e$ active in period $t$.

3.3 Planned events

3.4 Forecast table

[Explain how the low and high scenarios were produced, for example by varying $g$ between 3% and 7% per month.]

4. Current utilisation

Quotas and provider limits that apply: [list account quotas, API rate limits and licence caps with their current usage].

5. Headroom policy

Each tier keeps enough spare capacity to absorb a traffic spike and the loss of one failure domain while new capacity is added. The maximum planned utilisation $U_{\max}$ for a tier is:

where $N$ is the number of failure domains (for example zones), $F$ the number of domains that may fail at once, and $s$ the spike allowance. Example: $N = 3$, $F = 1$, $s = 0.2$ gives $U_{\max} = \tfrac{2}{3} \times \tfrac{1}{1.2} \approx 56\%$.

6. Resource models per tier

6.1 Web tier

Instances required at peak:

where $r_{\text{inst}}$ is the measured sustainable throughput of one instance. Example: $r_{\text{inst}} = 350$ req/s (load test LT-12), $D^{\text{peak}} = 8{,}670$ req/s, $U_{\max} = 0.56$ gives $n_{\text{web}} = \lceil 44.2 \rceil = 45$ instances.

6.2 Database tier

6.3 [Other tier]

[Repeat for each tier: caches, queues, storage, third-party APIs and licences. Note which models were validated by a load test and when.]

7. Bottleneck analysis

Time to exhaustion for a resource growing at rate $g$ per period from utilisation $U_0$ to threshold $U_{\max}$:

Example: database CPU at $U_0 = 0.69$, $U_{\max} = 0.77$, $g = 0.06$ per month gives $t \approx 1.9$ months.

The dependency diagram shows where saturation in one tier propagates.

8. Scaling plan

8.1 Automatic scaling

8.2 Planned scaling actions

8.3 Efficiency improvements

[List optimisations that reduce per-unit cost, with the expected effect on the models in section 6. Example: "Caching product lookups is expected to cut database reads by 35%, reducing CPU per transaction from 11 ms to 8 ms."]

9. Procurement and lead times

The latest order date for an item is:

where $L$ is the lead time and $B$ a safety buffer for installation and testing.

10. Cost projection

10.1 Projected cost

Unit cost is computed as:

10.2 Commitments and purchasing options

[Describe which baseline capacity will be covered by reservations or committed-use discounts, and which remains on demand. Example: "Commit 60% of the month-6 web baseline for one year; keep spikes on demand."]

11. Risks and assumptions

11.1 Assumptions

• Example: Request mix stays within 5% of the current read/write ratio.
• Example: No change in client retry behaviour.
• [Assumption]

11.2 Risks

12. Review cadence and accuracy tracking

Forecast error for each period is tracked as:

13. Appendices

13.1 Load test evidence

13.2 Data sources

[List the dashboards, queries and exports used, with time ranges, so the next planner can reproduce the numbers.]

13.3 Glossary

Standard and licence note

Based on common site reliability engineering and IT capacity management practice for demand forecasting, headroom and scaling plans. Original text written for this collection; example numbers are illustrative. Template licence: MIT.