Capacity & Sizing Model
Demand translated into resource, with the peak multiplier, the headroom and the failure-domain reserve stated as assumptions rather than buried.
The arithmetic from business volume to instance count, written so someone else can challenge each step. Every line is an assumption someone can disagree with, which is the point.
The shape
| Step | Value | Basis |
|---|---|---|
| Orders per year | 42 m | Business forecast, +18% YoY |
| Average orders/sec | 1.33 | 42m / 31.5m s |
| Daily peak factor | ×6.5 | Traffic analysis — 60% of volume in 5 h |
| Average peak | 8.6 /s | |
| Seasonal peak factor | ×9 | Last three Black Fridays vs mean day |
| Design peak | 78 /s | |
| Requests per order | 14 | Journey trace, p50 |
| Design request rate | 1 092 /s | |
| Throughput per instance | 95 /s | Load test, CPU at 70%, p99 within SLO |
| Instances at peak | 12 | 1 092 / 95 |
| Headroom for spikes | +30% | Absorbs a 30% forecast miss |
| Instances, healthy | 16 | |
| Zone failure reserve | +50% | Must serve peak with 1 of 3 zones lost |
| Provisioned peak | 24 | 8 per zone × 3 |
| Baseline (off-peak) | 6 | Autoscale 6 → 24 |
Storage. 42 m orders × 3.1 KB × 1.4 (indexes) = 182 GB/yr; 7-year retention plus 30% growth = 1.9 TB. Database. Peak 1 092 req/s × 2.4 queries = 2 620 queries/s; writes 78/s to primary, reads to two replicas.
What breaks first. At roughly 1.6× design peak the database connection pool saturates before the application tier does. Mitigation: connection pooler sized at 2×, and load shedding at the gateway above 1 400 req/s.
When you produce it
Before choosing instance types and before committing to reserved capacity. Redo it after the first real peak, when the assumptions become measurements.
Who reads it
Engineers sizing the deployment. Finance, who see where the reserved-instance commitment comes from. Operations, who set the autoscaling bounds. Anyone challenging the cost — which they should, and this is what makes that possible.
What good looks like
- Every factor has a stated basis. "×9 for seasonal peak" with three years of evidence is a number; without it, it is a guess with a decimal point.
- Throughput per instance comes from a load test at a defined utilisation and a defined latency target, not from a vendor datasheet.
- Failure-domain reserve is explicit. Sizing for exactly three zones means losing one takes you below capacity.
- What breaks first is identified. It is almost never the tier you scaled.
- Baseline and peak are both given, since the gap is the autoscaling range and most of the cost saving.
Common mistakes
- Sizing for the average and discovering the peak factor on the worst day.
- No failure reserve, so a zone loss during peak is an outage.
- Vendor throughput figures, measured on a workload unlike yours.
- Never revisiting it after real traffic arrives.