• Shadow / mirrored traffic (Module O-4): duplicate real requests to the new version and discard responses. Safe only if the path is read-only or side-effect-free — otherwise you have double-charged people.
• Traffic replay from access logs, which gives a genuinely realistic mix and key distribution, and which needs care about replaying writes and about personal data in the recorded requests (Module O-9).
• Canary at elevated weight: send one instance 5× its share and watch it approach saturation. Cheap, safe, and continuous — a standing measurement of your knee rather than a quarterly event.
• Direct load testing in production during low-traffic hours, with a kill switch and a clear abort criterion.

The controls that make this responsible: a bounded blast radius (one instance, one shard, one region), a separate test tenant so generated data does not pollute real accounts, and an explicit check on the side-effect paths — the classic accident is a load test that sends ten thousand real emails or charges a real card, which is why test accounts and provider sandboxes exist.

---

Reading the Results

Find what saturated, and expect it not to be the thing you were testing. The candidates, roughly in order of how often they are the answer:

Read the distribution, not the average. A bimodal shape usually means cache hit versus miss, and the p99 describes neither mode. A cliff means a resource hit a hard limit rather than degrading gradually.

Read the errors at the knee, because they tell you whether your protective mechanisms work. 503s with Retry-After mean shedding is functioning (Module A-8). Client timeouts and pool-exhaustion errors mean it is not, and you are collapsing instead of refusing.

Use Little's Law to connect the numbers (Module F-4): concurrency = arrival rate × service time. It converts a throughput target into a required concurrency, which is how you size pools and bulkheads rather than guessing. And it tells you what happens when service time triples: the concurrency requirement triples with it, which is the arithmetic behind almost every cascading failure in Phase 3.

---

Capacity Planning: Headroom Derived, Not Chosen

The question is not "how much traffic can we serve" but "how much of our capacity can we routinely use." The answer comes from what you must survive:

• Losing a failure domain. If you run three availability zones and must survive losing one, you can use at most ⅔ ≈ 66% of total capacity in steady state. With two zones, 50%. This is a concrete, defensible number that turns a budget conversation from opinion into arithmetic.
• A deploy. A rolling update removes instances; maxUnavailable of 25% means another 25% of headroom during every deploy.
• Growth between capacity reviews. If you review quarterly and grow 10% a month, you need ~30% of headroom just to reach the next review.
• A retry storm. Module A-6's amplification means offered load can rise sharply during an incident, and headroom is what lets you absorb rather than amplify.
• Cold caches. After a restart or a scale-out, per-request cost is temporarily higher.

Stack those and a steady-state utilisation target of 50–70% of the knee is not conservatism; it is the sum of specific, named requirements. Write them down that way, because "we run at 60%" is arguable and "we run at 60% because we must survive an AZ loss during a deploy while growing 10% a month" is not.

Model resource-per-request, so you can forecast without re-testing. For each significant endpoint, record CPU-milliseconds, database queries, cache operations and bytes transferred. A traffic forecast then converts directly into a resource forecast — and into a cost forecast (Module O-8), which is the same arithmetic with prices attached.

Plan against the binding constraint, and re-test after fixing it. Scaling the wrong tier adds cost and no capacity (Module A-8), and removing one bottleneck reveals the next, which is often in a completely different place. Capacity work is therefore iterative by nature: measure, fix, re-measure.

The stateful problem, and lead time

Stateless capacity is easy: add instances. The plan is really about the database, and the options have very different lead times:

Which produces the single most important planning rule in this module:

The lead time on your fix must be shorter than the time until you need it.

If sharding takes four months and you will exhaust vertical headroom in three, the project needed to start last month. This is why sharding is a planning decision rather than a scaling action, and why the useful capacity metric is not current utilisation but months of headroom remaining at the current growth rate — a number that should be on a dashboard and reviewed, because it is the only one that tells you when to start a long project.

Autoscaling, done correctly:

• Scale on the right signal. Queue age or in-flight concurrency, not CPU — I/O-bound workers have low CPU precisely while their backlog grows, so CPU-based autoscaling routinely scales down during a backlog (Modules P-19, A-8).
• Set the floor high enough to survive a spike during scale-up, because the autoscaler's reaction time is the window you must cover with static capacity.
• Scale up fast, scale down slowly, so a brief dip does not remove the capacity a returning spike needs.
• Remember the multipliers. More instances means more database connections (Module P-4) and more cold caches, so autoscaling the stateless tier can saturate the stateful one.

---

Launch Capacity

A launch is the event where all of this is tested at once, usually with no ability to iterate. The checklist that matters:

• Load test at the projected peak times a margin (2–3×), because launch projections are usually wrong in both directions and being wrong upwards is the expensive one.
• Verify shedding and degradation actually fire at the limit — this is Module A-7's untested-fallback warning and Module A-8's admission control, confirmed rather than assumed.
• Pre-scale rather than trusting the autoscaler. A launch spike arrives faster than instances boot.
• Check your quotas. This is the mundane launch blocker that catches people: cloud instance quotas per region, elastic IP limits, load-balancer target limits, provider API rate limits, third-party API tier limits, and database connection maximums. Quota increases can take days to approve, so they are checked weeks ahead, not on the day.
• Warm the caches before opening the doors, since a cold cache raises per-request cost exactly when volume peaks.
• Have the degradation switches ready and named — which features you will turn off, in what order, and who decides (Module A-7).
• Watch the leading indicators, not the error rate: queue depth, pool wait time, saturation (Modules O-1, A-8).

Why this matters in production: the recurring load-testing failure is a test that proved nothing — closed-loop, one endpoint, one hot key, a small dataset, twenty minutes — producing a confident number that the first real traffic peak contradicts. The recurring capacity-planning failure is different and worse: a team that knew utilisation was rising, could not name the binding constraint, and started the sharding project the month after they needed it. The first is fixed by methodology; the second by tracking months-of-headroom rather than percent-utilised.

---

Where This Shows Up in Your Stack

• Load generators: prefer tools with an arrival-rate (open) model — k6's constant-arrival-rate executors, Vegeta, Gatling's injection profiles. Tools defaulting to a fixed thread or virtual-user pool are closed-loop and will self-throttle under overload; if you must use one, verify how it handles latency growth before trusting the result. Generate keys with a realistic (Zipfian) distribution, and run the generator from outside the network you are testing so its own resources are not the constraint.
• PostgreSQL: pgbench measures the database in isolation, which is useful for separating database limits from application limits. During a test watch pg_stat_statements for the query that dominates total time (usually not the one you expected), pool wait time from the application side, max_connections headroom, replica lag, and dead-tuple accumulation on the write-heavy tables. The database is the most common binding constraint and the one with the longest lead time on a fix.
• Node.js: event-loop delay is the saturation signal (Module A-8), and one process uses one core — so a load test against a single process tells you about one core, not about a machine. Watch GC pause time and heap growth, which is where the soak test's leaks appear.
• Redis: rarely the bottleneck itself; the round trips to it usually are, so measure operations per request rather than Redis throughput. Watch evicted_keys under load — an eviction storm means your test's key distribution has exceeded the instance and your hit-ratio numbers are about to become fiction (Module P-12).
• Observability: you need Module O-1's instrumentation before the test, and the test is also a test of it — cardinality that survives normal traffic can take out a metrics backend at 10×, which is worth discovering deliberately rather than during a launch.
• Cost: a load test at 10× costs roughly 10× for its duration, plus any egress and per-request charges from real dependencies. Budget it, and prefer testing against sandboxes where the provider offers them (Module O-8).

---

Summary

• A load test produces four findings, not a number: the knee of the curve, which resource saturates first, the failure mode at overload (shed cleanly or collapse), and the values for limits, pools and autoscaling thresholds.
• Five test types find different bugs. Ramp finds the knee; soak finds accumulation — leaks, descriptor exhaustion, log-disk fill, unbounded in-process maps, vacuum/bloat feedback loops, a slowly growing replication slot; spike exposes cold caches, autoscaler lag, connection storms and retry amplification; breakpoint shows how you fail; and recovery — the one nobody runs — shows whether you exit Module A-8's metastable state without a human.
• A closed-loop generator cannot observe overload, because rising latency makes each virtual user send fewer requests, so the generator reduces its own load precisely when you needed it to persist. If your load test cannot make the system fail, suspect the generator before concluding the system is robust. Real users are open-loop.
• Coordinated omission makes reported latency wildly optimistic: a stalled virtual user does not record the requests it would have sent, so a two-second stall contributes one sample instead of forty. Use an open-loop generator that measures from the intended send time.
• The test must match reality in traffic mix, key distribution and data volume. A hot key measures your cache; use a Zipfian distribution. A query fast on 100,000 rows is not fast on 400 million. Discard the warm-up from steady-state numbers — and measure it separately, because that is your spike behaviour.
• Only production has the real data, mix and dependencies: shadow traffic (read-only or side-effect-free), log replay, an elevated-weight canary as a continuous measurement of the knee, and careful direct testing at low traffic. Bound the blast radius, use a separate test tenant, and check the side-effect paths — the classic accident is ten thousand real emails.
• Expect the bottleneck not to be what you were testing. Database connections and pool wait time are the most common answer; then database CPU/IO, event-loop delay, lock contention, and a downstream service's own limit. Read the distribution rather than the average, and read the kind of error at the knee — 503s mean shedding works, timeouts and pool exhaustion mean it does not.
• Headroom is derived, not chosen. Surviving the loss of one of three availability zones caps steady-state utilisation at ~66% (two zones: 50%); add deploy churn, growth until the next review, retry amplification and cold caches, and 50–70% of the knee is the sum of named requirements rather than caution. State it that way, because the arithmetic is not arguable.
• Model resource-per-request (CPU-ms, queries, cache operations, bytes) so a traffic forecast converts into a resource and cost forecast without another test.
• Plan against the binding constraint and re-test after fixing it, since scaling the wrong tier buys nothing and removing one bottleneck reveals the next somewhere else.
• The lead time on your fix must be shorter than the time until you need it. Vertical scaling takes minutes, a replica tens of minutes, sharding months — so the useful metric is not current utilisation but months of headroom at the current growth rate, which is the only number that tells you when to start a long project.
• Autoscale on queue age or concurrency, not CPU (I/O-bound workers have low CPU while backlogged), keep the floor high enough to cover the autoscaler's reaction time, scale up fast and down slowly, and remember that more instances means more database connections and more cold caches.
• For a launch: test at 2–3× the projection, verify shedding and degradation actually fire, pre-scale rather than trusting the autoscaler, check cloud and third-party quotas weeks ahead because increases take days to approve, warm the caches, name the degradation switches and who flips them, and watch saturation rather than error rate.

The next module, Chaos Engineering and Fault Injection, is the natural sequel. This module measured what happens under load; O-6 asks whether the failure-handling built across Phase 3 actually works — because a circuit breaker, a fallback, a retry budget and a failover are all untested code paths until something makes them run, and the first time they execute should not be during an incident.

---