Marketing tells the platform team that next month's campaign will double OrderService traffic. The default engineering answer, "we autoscale, it will be fine", is a hypothesis. Autoscaling adds instances; it does not add database capacity, connection slots, downstream rate limits or Kafka partitions, and it takes minutes to react (Scaling & Observability). Capacity planning is the discipline of finding which resource runs out first - before the traffic does.

The same thinking applies to failure. "What happens when the DB is 5x slower?" is a capacity question in disguise: a slower resource has one fifth of the capacity, so the same offered load is now an overload. The response (timeouts, bulkheads, shedding, graceful degradation) is the same toolbox whether the cause is traffic, a slow dependency or a dead cache.

Caveats. Real services are not M/M/c: service times have heavier tails (GC, cache misses), arrivals are bursty, work is not perfectly shared. That makes the real knee earlier. The simulation is a floor on how bad it is, not a prediction for your service. Take the shape; measure your own knee with a stepped load test (Benchmarking & Load Testing).

How to watch it in production: hikaricp.connections.active, hikaricp.connections.pending (non-zero means threads are waiting for a connection), hikaricp.connections.timeout and hikaricp.connections.acquire per instance, plus the database's own connection count (RDS/Aurora DatabaseConnections in CloudWatch). Deep dive in Database Performance.

Now the worked example the campaign needs. Take the model above and double the peak from 1500 rps to 3000 rps. Compute every tier's requirement instead of assuming it scales.

The answer in one sentence for the stakeholder: the application tier will scale, the database and the payment provider will not, and we have a 1.7x runway on the DB before we must fix queries per request, add a read replica or cache. That is a capacity plan; "autoscaling will handle it" is not.

Each card follows the same template: what you will see, how far it spreads, what protects you and how to rehearse it. Numbers are arithmetic from the formulas above; none of these six were reproduced in the sandbox beyond what the earlier labs show (marked).

A protection you have never exercised is a hypothesis. Rehearsal turns it into evidence, in three increasing levels: tests in CI, fault injection in staging, and game days in production with a controlled blast radius.

Plain Java 21, no dependencies: javac Hockey.java && java Hockey, javac DbSlow.java && java DbSlow, javac Capacity.java && java Capacity. All three are deterministic (fixed seeds) except for tiny differences you get from changing the seed.

• Q: How do you decide how many instances a service needs?
  Per instance: min over resources of capacity / time-per-request (CPU, threads, connections), times a target utilisation (50-70 %). Fleet: ceil(peak / planned) plus N+1 (or AZ) headroom. Then check every shared resource (DB QPS, connections, downstream limits, partitions) for the same peak.
• Q: Why does latency explode near 100 % utilisation?
  Queueing: mean response time = service time / (1 - ρ) for M/M/1 - 2x at 50 %, 10x at 90 %, 50x at 98 %. The tail is worse. Pooling (more servers) delays the knee: an 8-worker pool is 1.8x at 90 %.
• Q: We doubled the instances and throughput did not move. Why?
  The bottleneck is shared: DB CPU/IO or QPS, connection slots, a lock, a downstream rate limit, a hot partition. Evidence: app CPU low, hikaricp.connections.pending high, DB saturated. Fix queries per request, scale the shared tier, or remove coordination.
• Q: How does instances x pool size interact with the database?
  Total connections = instances x maximumPoolSize must stay under the DB budget (max_connections minus reserve); autoscaling max must be derived from it. RDS Proxy / PgBouncer multiplex when it does not fit.
• Q: The DB is slow and unrelated endpoints are failing. Why?
  Shared Tomcat threads are blocked waiting on the DB. Isolate with a bulkhead or separate pools, fail fast on connection acquire, keep health checks off the DB path. Our model: /ping p99 413 ms and 25.8 % errors → 1 ms and 0 %.
• Q: What is load shedding and where do you put it?
  Rejecting some work early so admitted work stays fast. At the edge (rate limits), then admission control by queue wait in the service, before expensive work. Send 503 + Retry-After; clients back off with jitter.
• Q: A new release leaks 4 MB/min. Why is that hard to catch?
  The OOM comes after hours (259 min in the example) when the deploy looks healthy. Canary + automatic rollback on heap-after-GC slope and SLO burn, heap dump on OOM, and restarts as mitigation only.
• Q: How do you rehearse failure safely?
  Steady-state hypothesis, small blast radius, numeric abort criteria, tool-driven faults (Toxiproxy, tc netem, FIS), run in staging first, then production at low traffic; automate the cheap ones in CI.
• Q: What does the Universal Scalability Law add to Amdahl's Law?
  A coherency term β: contention (α) limits speed-up to a plateau (Amdahl), coherency cost makes throughput decline beyond a peak N = sqrt((1-α)/β). Fit α and β from at least 5 measurements.
• Q: Why is autoscaling not a capacity plan?
  It adds app-tier capacity after minutes of delay and does nothing for DB, quotas, partitions, or warm-up; it can amplify DB overload by adding connections. Plan the shared limits and pre-scale known events.

• Measure First - Little's Law, percentiles, USL basics.
• Distributed Systems & Messaging - retries, breakers, hedging, queues.
• Database Performance - the Hikari pool and the DB wall in depth.
• AWS Compute & Containers - the next page: CPU limits, throttling and container memory.
• Scaling & Observability - reacting to load in time and watching it.
• Spring: Caching & Resilience - Resilience4j bulkhead/breaker wiring.