Size the Stateless Tier with Unit-Labeled Assumptions
Capacity planning for a stateless tier converts a 10x seasonal peak into an instance count using unit-labeled assumptions. This hands-on lesson works the storefront math from 1,200 RPS to 27 instances, then adjusts for zone failure. Covers: Requests per second, peak factor, target utilization, surge headroom, p95 latency criteria, Availability Zone N+1 capacity, startup delay, scaling granularity. Practice: Stateless tier sizing. Prerequisites: Load balancing and autoscaling basics.
An interviewer says, “We expect 10× seasonal spikes, and we can’t fall over on Black Friday.” The behavior being scored is not recall of a provider benchmark. It is whether we can turn that statement into a transparent capacity estimate, label each assumption, and name the evidence that could change it.
For the seasonal storefront, let’s size the stateless API tier behind a load balancer in one Region with multi-Availability Zone redundancy. A request rate is the number of requests processed per second, written as requests per second (RPS). We need a small load model before we choose an instance count.
Build a unit-labeled load model
Start with inputs that can be challenged without making the calculation vague. Suppose the storefront averages 120 RPS outside the promotion window. A stated 10× peak factor gives a planned peak of 1,200 RPS. These are fictional placeholders, not production measurements.
Input | Placeholder Value | Meaning |
Average demand |
| Normal API request rate |
Peak factor |
| Seasonal demand relative to average |
Planned peak |
|
|
Tested per-instance capacity |
| Capacity under stated test conditions |
Target utilization |
| Operating limit before added surge margin |
Surge headroom |
| Extra instances beyond the calculated need |
Latency constraint |
| Test acceptance criterion, not a promise |
The ...