You already have futures and promises for asynchronous results. When is a future the wrong abstraction and an asynchronous stream the right one?

## The single distinguishing property: cardinality over time A **future** models *one* asynchronous outcome. It starts pending and moves exactly once into a terminal state — a value or an error. It has no notion of the second value, because there is no second value. An **asynchronous stream** models *a sequence* of asynchronous outcomes: zero or more items, followed by at most one terminal signal that says either *finished normally* or *failed*. Everything else that differs between the two abstractions follows from that. ## What follows from the cardinality difference **1. There is a rate dimension.** With exactly one hand-off, the producer cannot be *too fast*: there is one value and one delivery. As soon as a producer can emit repeatedly, its rate can exceed the consumer's, and the excess has to be handled. That is why streams carry flow control machinery and futures do not — not because stream libraries are more thorough, but because the problem does not exist in the single-value case. **2. There is a lifecycle to manage.** A future needs a completion handle. A stream needs a **subscription**: something the consumer holds to signal interest, express demand, and cancel. Cancellation is far more consequential here, because a stream can still be producing when the consumer walks away, whereas a future is a single event that has either happened or not. **3. Completion becomes a separate signal.** For a future, having a value *is* completion. For a stream, the last item and *the end of the stream* are different events, and a consumer often needs to know the difference — to close a file, flush a batch, or emit a total. **4. Memory profile.** A future of a collection forces materialization: the whole collection exists before the consumer sees anything. A stream of the same data can be processed incrementally, with only a bounded window in memory. For a large export or a scan of a big table, that difference decides whether the service survives. **5. Latency to first result.** With a future you wait for everything; with a stream the first element is usable immediately. This is what makes streaming attractive for user-facing progressive rendering and for pipelines whose stages can overlap. ## Concrete signals that you should be using a stream - Results are paginated or chunked, and today you loop, accumulate into a list and return a future of that list. - The source is a subscription or a server push: notifications, change feeds, telemetry, chat messages. - The source has no end: sensor readings, market data, a tailed log. - You want to start processing before the source is finished, or to stop early after finding what you need. - The producer's rate is independent of your consumption rate and you care about bounded memory. ## Signals that a future is the right answer - Exactly one result, known in advance: a lookup, a command, an RPC. - A small collection you genuinely want in one piece, where the whole thing comfortably fits in memory and the caller wants it as a unit. - Code that should stay simple. Streams add operators, subscription lifetimes, cancellation semantics and flow control, all of which cost readability and debuggability. Do not pay for them where cardinality is one. ## The conversions between them The two abstractions interconvert, and knowing the conversions shows fluency: - **Stream to future:** collect the items into a value, or take the first item, or reduce to an aggregate. Note that collecting reintroduces full materialization and its memory cost. - **Future to stream:** a stream that emits one item and then completes. - **Future of a stream:** common when opening the source is itself asynchronous — connect, then stream. A useful mental model: a future is a stream restricted to exactly one item, with the flow-control and lifecycle machinery removed because that restriction makes it unnecessary. ## In an interview Say it in one line — one outcome versus many over time plus a terminal signal — then give the three consequences that matter operationally: incremental processing, bounded memory instead of full materialization, and the existence of a rate mismatch that only appears once there is more than one item. Add that you would keep futures where cardinality is genuinely one, because the simpler abstraction is easier to reason about.