The notebook, in full. Sorted newest first.

A deterministic Java hedging simulation where a p95 threshold cuts p99 from 200ms to 43ms for 3.7% extra load, while a p99 threshold improves nothing and burns the most wasted work. Hedging is a latency technique you buy with capacity.

A deterministic Java queueing simulation where p99 stays at 10ms through rho=1.00, then jumps to 109ms at rho=1.05 and 605ms at rho=1.30 while service time stays fixed.

A deterministic Java simulation where baseline p99=34ms becomes fan-out p99=597ms without changing the downstream latency sampler. Average latency is structurally incapable of catching that tail pain.

Resilience composition in structured concurrency comes down to one rule: keep each policy a separable layer that fires visibly in logs, or rebuild the complexity you were trying to remove.

The real ceiling on a fan-out request is downstream capacity, not the thread count. One semaphore per dependency type stops a hot path from draining the pool everyone else shares. How we set them and what changes when traffic shape shifts.

Past basic fork-and-wait, two workflow shapes dominate. Streaming progress as subtasks finish works for user-facing flows. Nested scopes that mirror the service tree work for fan-out into fan-out. What each one costs.

Not every failure is a timeout. A failed risk check turns the rest of the fan-out into wasted work, so the fix is to throw inside the subtask, cancelling its siblings before they burn capacity. The pattern, the implementation, and where it backfires.

Timeouts in distributed code are routine, not exceptional. The real question is whether a missed deadline should fail the whole request or return what made it back in time. The three timeout shapes we run and when each one fits.

Most concurrency bugs in service code come from missing lifecycle, not missing parallelism. A scope that owns its forks is what makes task lifetime visible in the code that started them. The bugs that go away when scopes are right.

Benchmark numbers for virtual threads versus reactive code disagree wildly because the workload dictates the answer, not the model: I/O-bound code usually benefits, CPU-bound rarely does, and non-blocking moves work without removing it.

StructuredTaskScope on its own is a parallel-fetch helper, and the resilience policy that makes it usable against a flaky downstream belongs in one handler instead of duplicated at every call site.

Long CompletableFuture chains look fine in code review and painful in incident calls because a failed call leaves its siblings still running, and a structured scope is what cancels them on the way out.

A microservice that swaps its executor for virtual threads loses the thread-pool ceiling but gains a different operational surface: orchestrating fan-out cleanly, watching pinning instead of pool depth, and noticing that downstream capacity is now the limit.

The reason web servers moved to reactive code was that platform threads cost too much to dedicate one per blocking request, and virtual threads remove that cost without asking the request handler to look any different.

Discover Java's virtual threads revolution with Project Loom. Learn why Java's threading model is changing forever, performance benefits, migration strategies, and real-world implementation examples. Complete guide to lightweight concurrency in Java 21+.