6. Real-World Scenarios & Case Studies

6.1 Flash sale / e-commerce (thundering herd on inventory)

Scenario: 200k users refresh a product page in the 10 seconds around a sale's start time; all attempt to buy 5,000 units of a limited item.

What breaks in the wild: optimistic-locking retries storm the DB; cache stampede on the product-detail cache key when it expires exactly at sale time; payment-gateway calls queue up behind a DB row lock on the inventory counter.

How to simulate:

Open-loop ramp from 100 → 50,000 virtual users over 15s (spike test, §4.3).
Model realistic behavior: 95% of users only view the page (read-heavy GET), 5% attempt checkout (write, contended resource) — Locust's weighted @task or k6 scenarios express this mix well (see §7).
Verify: does the inventory count ever go negative (correctness under concurrency)? Does p99 for browsing degrade because checkout writes starve DB connections shared with reads? (Answer: use separate connection pools/read replicas.)

6.2 Ticket booking (seat/slot contention, hold-and-confirm)

Scenario: Concert ticket sale — thousands compete for the same 500 seats, with a "hold for 5 minutes while paying" step.

What breaks: held-but-unpaid seats leak if the release-on-timeout job isn't tested under load; DB deadlocks from concurrent updates on the same seat-map rows; WebSocket/polling connections for live seat-map updates fan out to O(users) — tests must include the read-side broadcast load, not just the write path.

How to simulate: multi-stage scenario — select seat -> hold -> pay (with injected 2-10s delay to mimic a payment gateway) -> confirm/expire. This is a stateful, multi-step scenario best expressed in Locust (Python, stateful TaskSet) or k6 (JS, sequential steps in one VU iteration) rather than a stateless single-endpoint hammer tool like wrk.

6.3 Payment gateway (tail latency + idempotency under retry storms)

Scenario: a client times out at 3s and retries; if the original request actually succeeded server-side just after the client gave up, a naive retry double-charges.

What to load-test: correctness under retried concurrent load — send the same idempotency key twice concurrently and assert exactly one charge occurs. This is a correctness-under-load test, not just a throughput test — write a small Go/Python harness that fires N duplicate requests concurrently (see §9) and asserts on the resulting ledger state.

Scenario: celebrity account posts; millions of followers' feeds must reflect it, either via fan-out-on-write (push to followers' feed caches) or fan-out-on-read (compute at read time).

Load test focus: fan-out-on-write load-tests the write path's amplification (1 post → millions of cache writes — test with a "hot user" whose follower count skews the distribution, not just uniform random users); fan-out-on-read load-tests read-path aggregation latency as follower/following graphs grow — percentile latency should be measured per user tier (a load test that only reports a global p99 will hide that celebrity-adjacent reads are 50x slower).

6.5 Video streaming (bandwidth + jittery mobile networks)

Scenario: adaptive bitrate streaming over mobile networks with variable bandwidth, latency, and packet loss.

Load test focus: this is as much a network condition test as a throughput test. Use tc netem (§8) to simulate 3G/4G profiles (high latency, jitter, 1-2% packet loss) while running normal HTTP range-request load against the CDN/ origin, and verify ABR (adaptive bitrate) logic downgrades quality instead of stalling, and that origin shielding correctly absorbs a thundering herd of cache-misses when a new episode drops.

6.6 IoT telemetry ingestion (connection churn, small payloads, at massive scale)

Scenario: millions of devices each send a small payload every 30s, with frequent connect/disconnect (unlike a browser, IoT devices often don't keep long-lived connections due to intermittent power/network).

Load test focus: here connection setup cost (§2.1) dominates over in-connection throughput. Benchmark connections/sec, not just requests/sec on warm connections — tools like wrk with --latency and low keep-alive, or a custom Go/Rust harness that deliberately opens a fresh connection per request (see §9), model this far better than default keep-alive-friendly tools.