A junior engineer implements an aggregation gateway endpoint that calls a pricing service, an inventory service, and a reviews service, then merges the three JSON responses into one payload. In their code, each call uses a blocking HTTP client and is invoked one after another inside a single method. What is wrong with this implementation, and what would fix it?

## What concurrent fan-out requires Making a downstream fan-out actually concurrent requires a concrete mechanism, not just "calling three services." - **In a thread-based stack** this typically means submitting each call as a task to an executor and getting back a future (`CompletableFuture.supplyAsync` for each call, then `CompletableFuture.allOf(f1, f2, f3)` to join), or using async/await in languages that support it so each call starts before the previous one's result is needed. - **In a reactive stack** it means composing publishers with an operator like `Mono.zip` or `Flux.merge` so subscriptions to all three sources happen up front and the pipeline completes when all have emitted. Either way, the key property is that the three network calls are all in flight at the same time, and the gateway blocks or awaits exactly once, on the join, rather than three separate times. ## Why it matters This matters because the entire value proposition of aggregation is amortizing round-trip cost. If the fan-out inside the gateway is accidentally sequential, the aggregate response time becomes the sum of the three call latencies instead of roughly the maximum of them. A gateway meant to turn three 100ms calls into one 100ms-ish response instead turns them into a 300ms response, which can be slower than letting the client call the three services directly if they happen to be reachable in parallel from the client too. The whole architectural investment in an aggregation layer is wasted by this one implementation mistake. ## What correct concurrency costs Building correct concurrency has real costs beyond just calling the right API. - The gateway needs a **bounded resource pool** -- threads, connections, or both -- sized for its expected concurrent load, because unbounded per-request thread or connection creation degrades badly under traffic spikes. - **Error handling** also becomes more delicate: when three calls run concurrently and one throws, the code must decide whether to salvage the other two results or fail everything, and naive use of a joining primitive like `allOf().join()` will propagate the first exception and discard the rest unless each future's result is inspected individually with something like `exceptionally()` or `handle()`. - **Tests** get harder too, since concurrent code can have race conditions and non-deterministic ordering that simple sequential code never exhibits. ## Failure modes 1. **The sequential-await bug.** In production, a common failure mode from get-it-working-quickly code is exactly the sequential-await bug described in this question: it passes functional tests, since the merged output is correct, and only shows up as a latency regression once load testing or real users notice the endpoint is slower than expected. 2. **Forgetting per-call timeouts.** A second failure mode is forgetting per-call timeouts even after fixing the concurrency: if the join waits on all three futures with no individual timeout, one hung downstream call can stall the entire gateway response indefinitely, converting a should-be-fast concurrent fan-out into a request that never returns. 3. **Unbounded thread creation.** A third, more insidious failure is unbounded thread creation per request; under a traffic spike this can exhaust memory or hit OS thread limits, crashing the gateway process instead of gracefully shedding load. ## Where it shows up A well-known real-world illustration is Netflix's historical use of Hystrix, where each downstream call in an aggregation flow was wrapped as a Hystrix command executing on its own dedicated thread pool, with results composed via futures or reactive Observables once all commands resolved or timed out -- explicit infrastructure built specifically to make concurrent fan-out safe and boundable at scale. In simpler modern stacks, a Node.js gateway using `Promise.all([callA(), callB(), callC()])` or a Spring WebFlux gateway using `Mono.zip(callA(), callB(), callC())` achieve the same concurrent-fan-out-then-join shape with far less code, but the underlying requirement -- start all calls before awaiting any of them, bound the resources involved, and time each call out independently -- is identical regardless of the specific framework.