The notebook, in full. Sorted newest first.

110 rps against 100 rps of capacity drops goodput to 42 rps, and retries make it worse. A deterministic Java model.

A p95 hedge cuts p99 from 200ms to 43ms for 3.7% extra load; a p99 hedge buys nothing. Hedging is paid for in capacity.

p99 holds at 10ms through rho=1.00, then jumps to 109ms at 1.05 and 605ms at 1.30. Service time never changes.

Baseline p99 is 34ms; five-way fan-out pushes it to 597ms with the same downstream sampler. The average never moves.

Each resilience policy stays a separable layer that fires visibly in logs, or you rebuild the complexity you removed.

Downstream capacity caps fan-out, not thread count. One semaphore per dependency stops a hot path draining the pool.

Streaming results as subtasks finish suits user-facing flows; nested scopes mirror the service tree. What each costs.

Throwing inside a subtask cancels siblings before they waste capacity, and sometimes that is wrong. Where it backfires.

Should a missed deadline fail the request or return what made it back in time? Three timeout shapes and where each fits.

Most concurrency bugs come from missing lifecycle, not missing parallelism. A scope makes task lifetime visible in code.

Virtual threads or reactive is a workload question. I/O-bound code gains, CPU-bound rarely does, benchmarks show why.

Retry, fallback, and timeout policy around StructuredTaskScope belongs in one handler, not at every call site.

CompletableFuture chains leave failed calls' siblings running. A structured scope cancels them on the way out.

Swap in virtual threads and the pool ceiling disappears. Fan-out, pinning, and downstream limits take over.

One virtual thread per request, ordinary blocking handlers, and load tests that show where the gains come from.

Virtual threads change the cost of waiting, not the speed of work. Why blocking Java code scales again on Project Loom.