A team is deciding whether to build a new service's asynchronous layer around demand-driven reactive streams, around suspending sequential code (coroutine or async-await style), or around plain futures dispatched on an event loop. How would you reason about that choice?

## Decide on problem shape, not on fashion All three options solve *do not park a thread while waiting*. They differ in what else they impose. The failure mode of this decision is choosing the most powerful model for the whole service and paying its cost on the ninety percent of code that never needed it. ## The axes that actually decide it ### 1. Cardinality of the result Single outcome per operation — a lookup, a command, an RPC — is future or suspension shaped. A sequence over time with a rate the consumer does not control is stream shaped. Most services are overwhelmingly the former with a few of the latter, which argues for a default plus exceptions rather than a single model everywhere. ### 2. Whether flow control is a live requirement Demand signalling exists to keep in-flight work bounded when a producer can outpace a consumer. Ask concretely: is there a path where the source's rate is independent of your consumption rate? Ingest from a broker, change feeds, large scans, fan-out to slow sinks — yes. A handler that makes two calls and returns a response — no, because inbound concurrency limits already pace everything. Adopting streams for flow control you do not need is pure cost. ### 3. End-to-end non-blocking reality The benefit depends on the *whole* path. If a driver, an authentication library or a serializer blocks, you hop to a bounded thread pool at that point and inherit its queue and its saturation behaviour. You then carry the full complexity of the async model while your capacity is still set by that pool. Audit the dependencies before deciding; this single check has reversed many of these decisions. ### 4. Debuggability, and who pays for it This is the most underweighted axis. Operator pipelines break the correspondence between the physical stack and the causal history: a failure shows the delivery machinery rather than the call that started the work, thread-scoped context does not follow the data, and stepping through a pipeline in a debugger is genuinely hard. Sequential suspending code preserves an ordinary reading order and usually a reconstructed causal trace. Multiply the difference by every engineer, every incident, and every new hire. ### 5. Virality and mixing Asynchrony spreads through signatures: one suspending or stream-returning call forces the shape on every caller up the chain. Mixing models means bridges at the boundary, and bridges are where threads get parked, pools get exhausted and deadlocks appear. Choose one default per service, make the boundaries explicit, and put the bridges in as few places as possible. ### 6. Ecosystem and operational fit Do your libraries, tracing, metrics and profilers understand the model? Does the framework let you express a per-stage concurrency limit? Can you observe demand and queue depth, which is what you will need at three in the morning when latency climbs? A model you cannot observe is a model you cannot operate. ## What the evidence usually says Ask what has actually hurt this team in production. If incidents are *out of memory because a queue grew*, demand signalling addresses the root cause directly and is worth its price on the affected paths. If incidents are *thread pool exhausted because everything was blocked*, any non-blocking model helps and the simplest one wins. If incidents are *nobody could work out what this pipeline does*, the answer is not more operators. ## A defensible position - **Default:** sequential suspending code for request and response work. It preserves reading order and debuggability, gives structured lifetimes and cancellation, and covers the large majority of handlers. - **Streams:** for paths that are genuinely streaming, unbounded in rate, or multi-stage with a mismatch — ingest, exports, fan-out, subscriptions. Introduce them as a bounded region with an explicit boundary rather than as the service-wide idiom. - **Futures:** as the lingua franca between libraries and models. Almost every ecosystem can produce and consume them, so they are the cheapest interop currency; keep them at seams rather than as the primary programming style. - **Non-negotiables regardless of choice:** bounded queues everywhere, an explicit concurrency limit per stage, timeouts that cancel, cancellation that propagates, and end-to-end context propagation that does not depend on thread affinity. ## How to present this in an interview Do not answer with a technology. Give the axes, state which evidence you would collect — incident history, the blocking audit of dependencies, the shape of the traffic — and then commit to a defensible default with named exceptions. The signal being looked for is that you can price complexity against the property it buys, and that you know reactive streams buy bounded behaviour under overload rather than throughput.