Mapping each queued item to its own asynchronous call yields a source of sources: what does a flattening step then do?

## One level too many A mapping step is **one-to-one**: it takes an element, returns a value, and the sequence keeps its shape. That holds only while the value is a value. The moment the mapping returns **another asynchronous call**, the shape changes, because the call is not a result - it is a *source* that will push its own result later. The mapping now produces a sequence whose elements are sources, and anything subscribing downstream receives sources, not answers. Take a moderation queue where every arriving item must be sent to an external classifier. Mapping each item to its classification call gives you a source of calls. Nothing has been classified. Nothing has even been sent. Removing that extra level, and issuing the calls in the process, is the whole job of a **flattening step**. ## What the flattening step actually does Three jobs, and only the first is obvious. 1. **It subscribes.** A **cold** inner source defines work per subscriber and does nothing until something subscribes to it, so the flattening step is what issues the call. This is why an element that the strategy decides to discard costs nothing downstream - its call is never made at all. 2. **It re-emits.** Whatever an inner source produces is republished onto a single outer sequence, element by element as it arrives. It is not collected into a list, not paired with the element that produced it, not deduplicated. 3. **It decides completion.** The flattened sequence completes when the outer source has completed **and** every inner source still alive has completed. Completing as soon as the last element was mapped would truncate results that were still in flight. The second and third points are what separate a flattening step from a plain transformation: it owns subscriptions, so it owns lifetime. ## The strategy is the real content Every flattening step answers two questions, and the answers are what interviewers are after: **how many inner sources may be live at once**, and **what happens to work already in flight when a new element arrives**. | strategy | inner sources live at once | order of results | what it gives up | |---|---|---|---| | sequential concatenation | one | element order | throughput: one call per round trip | | bounded concurrent merge | up to the bound | completion order | element ordering | | switch to newest | at most one, previous cancelled | only the latest element's result | results of superseded elements | | ignore while busy | one | element order of the kept elements | elements that arrived during a call | None of these is a default worth accepting without thought. In the moderation console, the queue itself wants throughput and probably tolerates interleaving, so bounded merging fits. The detail pane beside it, which loads whichever item is highlighted, wants the newest and nothing else, so switching fits. A button that triggers one expensive re-classification wants ignore-while-busy, so a double press costs one call. The same pipeline can legitimately use three different strategies in three places. ## Symptoms when the flattening is wrong or missing - **Results arrive as sources.** In a typed pipeline this is a compile error; in an untyped one it renders as something meaningless. The mapping was never flattened. - **The sequence completes before any result arrives.** Something waited on the outer source only and ignored the inner ones. - **A burst of arrivals becomes an identical burst downstream.** The merge has no useful bound, so every queued element has a call in flight simultaneously. - **Results are recorded in an order nobody expected.** A concurrent merge was chosen where element order was part of the requirement, and the defect appears only when inner latencies differ - which is rarely true in a test with stubbed calls. ## Why this is asked The map-versus-flatten distinction is a screening question because it separates someone who has assembled a pipeline from someone who has only read about one. The real interview, though, is the follow-up: *which strategy, and why that one here*. An answer that stops at "it flattens the nested sources" is incomplete, because the flattening is mechanical and the strategy is the design decision. A strong answer names the two axes - concurrency and what happens to in-flight work - and then picks a strategy for the specific case in front of it, saying out loud what that choice costs. One last property worth internalising: because the flattening step owns the inner subscriptions, cancelling the flattened sequence propagates down into them. Whether that actually stops the outbound calls depends on whether each inner source honours cancellation, which is a property of how that source was built rather than of the flattening strategy.