Why does one dependency with no non-blocking path change whether asynchronous data flow is worth adopting at all?

## The benefit is a property of a whole path Asynchronous data flow buys one thing: a unit of execution is not held during a wait, so the number of requests in flight stops being bounded by the number of workers you can afford. That benefit is **not additive across a service**. It belongs to a request path only if *every* wait on that path releases its worker. One stage that holds a worker for the duration of a call reinstates, for that path, the resource cost the whole design was chosen to avoid. This is what people mean when they say the style has to go *all the way down*. It is not a purity argument. It is arithmetic: if the projected capacity was computed from "workers are never parked", and one dependency parks a worker for a hundred milliseconds on every request that touches it, then the projection is wrong for every such request. ## Wrapping is not converting The most common mistake in this material is believing that placing a synchronous call inside a pipeline stage converts it. It does not. Whatever the surrounding shape, the call still occupies the worker that executes it for its full duration. The pipeline notation moved; the cost did not. The real conversions are narrower than people expect: - The dependency **exposes a genuinely non-blocking client**, driven by readiness or completion notification underneath, so the calling worker is released while the answer travels. - The dependency is **removed from the request path** entirely — answered from something the service already holds, or deferred to work done outside the request. - The dependency is **isolated** behind its own pool of workers whose job is to be parked, so the parking happens somewhere it does not consume the capacity everything else depends on. Nothing else changes the arithmetic, and only the first two recover the saving. ## What isolation actually costs Isolation is a legitimate escape, and it is worth being exact about what it buys and what it charges: | Aspect | Converted path | Isolated blocking dependency | |---|---|---| | Workers held while waiting | None | One per call in flight | | Memory model for that path | Pipeline state | The old per-call cost | | Sizing input | Not required | Calls in flight at peak | | New operational surface | — | A boundary to size, watch and alert on | | Behaviour when the dependency slows | Demand builds up | The isolated pool saturates | The sizing row is where teams go wrong. A pool that fronts a parking dependency must be sized by **how many calls to it are outstanding at once**, which by **Little's Law** is the arrival rate of those calls multiplied by how long each takes — not by the machine's core count, which describes compute capacity rather than waiting capacity, and not by total request rate, which ignores duration entirely. Ten calls a second at two hundred milliseconds each needs about two outstanding; the same rate at two seconds each needs about twenty. ## Doing the inventory before the decision Because the benefit is path-shaped, the evidence that supports or kills adoption is an inventory, produced before anyone writes code: 1. List every outbound dependency the service touches on a request path — data stores, other services, caches, file access, third-party clients, anything that consults the network or the disk. 2. For each, record whether a non-blocking path genuinely exists, or whether the only access is a call that parks its caller. 3. Weight each by the fraction of traffic that touches it. 4. Recompute the capacity claim using only the converted fraction. If the weighted converted fraction is small, the honest conclusion is that the workload might suit the style but the surrounding ecosystem does not — a perfectly good reason to say no, and a much cheaper discovery before the rewrite than after it. ## Why interviewers reach for this It separates candidates who have adopted the paradigm from candidates who have read about it. The reading gives you the benefit; the adoption gives you the discovery that one stubborn dependency quietly turned a projected capacity multiple into a modest improvement, plus a new pool nobody had planned to operate. A candidate who volunteers the dependency inventory unprompted has almost certainly lived it.