skip to content

When one source is appended after another, when is the second source subscribed, and what does that delay cost?

level: middleimportance: nice to knowfreq 30%

answer

  1. one source live at a time
  2. the next subscription waits for a completion
  3. order bought, a window paid
  4. an endless first source starves the rest
  5. a failure stops the chain, not a fallback

basics

~20 s

Only after the first source completes. Appending buys a strict ordering guarantee and pays for it with a gap: a second source that is already running loses everything it produced during that window, a first source that never completes starves it, and a first source that fails prevents it from running at all.

solid answer

~50 s

Sequential appending subscribes to the sources **one at a time**: the second subscription is created only when the first signals completion. What you buy is ordering — every value of the first source is delivered before any value of the second, with no interleaving. What you pay is the window between the two subscriptions. If the second source produces values independently of subscribers, everything it produced while the first was running is simply missed, because nobody was subscribed. If the first source never completes, the second never runs at all. And if the first source **fails**, the failure is propagated and the second source is never subscribed either — appending preserves order, it does not provide a fallback. The classic use, showing a stored snapshot and then following live updates, hits all three traps at once.

code

pseudocode · 8 lines
pseudocode
function append(first, second):
    subscribe to first with:
        on value(v):    emit v
        on complete:    subscribe to second with:
                            on value(v):  emit v
                            on complete:  emit complete
                            on failure(e): emit failure e
        on failure(e):  emit failure e      // second is never subscribed

go deeper

for a junior

Remember the sequence: the second source is subscribed only after the first signals completion, so exactly one source is live at any moment and the output never interleaves them.

for a middle

Explain both sides of the trade — a strict ordering guarantee and bounded load, against a window in which a later, independently running source produces values nobody is subscribed to receive.

for a senior

Recognise the snapshot-then-live-feed shape and close the gap deliberately: buffer the live feed from the start, or replay from a position recorded before the snapshot, and say which staleness you accepted.

for a principal

Draw the line between phases and inputs. Appending suits phased startup; using it for independently live inputs silently trades correctness for ordering, and that trade should be an explicit decision rather than an operator choice.

## Appending means subscribing later Sequential appending is the only one of the combining rules that does not have all its sources running at once. It holds an ordered list of sources, subscribes to the first, forwards its values, and only when that source signals completion does it subscribe to the next. At most one source is live at any moment. That is the whole mechanism, and every property follows from it. ## What the ordering guarantee buys - **No interleaving.** Every value of the earlier source is delivered before any value of the later one, regardless of how fast each produces. - **A deterministic sequence.** Two runs over the same inputs produce the same output order, which combining rules that subscribe concurrently cannot promise. - **Bounded concurrency by construction.** Only one source is doing work, so appending several expensive sources never multiplies load the way subscribing to them all at once would. ## What the gap costs 1. **Values produced before the subscription are missed.** A source that runs independently of its subscribers — a live feed that is already flowing — does not replay what happened before you arrived. Everything it produced while the first source was still running is gone, and nothing reports the loss. 2. **A first source that never completes starves the rest.** An endless source at the front of the list means the later sources are never subscribed. The symptom is that half your pipeline appears not to exist. 3. **A failure in the first source ends the whole thing.** Appending forwards the failure downstream and never subscribes the next source. It looks like a fallback chain and is not one; a fallback requires a rule that reacts to the failure by switching, which is a different concern entirely. 4. **The switchover has a latency spike.** The later source's start-up cost — opening a connection, taking a snapshot, warming a cache — is paid at the boundary, while the output is silent. On a display, that shows up as a visible pause between the two phases. ## Appending against subscribing to all at once | property | sequential appending | subscribing to every source at once | |---|---|---| | sources live at a time | one | all | | output order | all of one, then all of the next | interleaved by arrival | | values before subscription | missed for later sources | nothing is missed | | effect of an endless first source | later sources never run | unaffected | | downstream load | one source's worth | the sum of all sources | ## The classic use and its trap A terminal wants to show the stored price list immediately and then follow live price updates. Appending the stored list before the live feed reads perfectly and is wrong in a specific way: 1. The stored list is read and its values are emitted, which may take a noticeable time. 2. The list completes, and only then is the live feed subscribed. 3. Every price change that occurred **during step 1** was published to nobody. The display is now permanently stale for exactly those items, and it will look correct — it has a full list and a live feed — until someone notices a price that never updates. The repairs are all about closing the window: - **Subscribe to the live feed first** and hold its values in memory, then emit the stored list followed by the held values once the read completes. - **Record a position before taking the snapshot** and have the live feed replay from that position, so the overlap is delivered rather than missed. - **Accept the gap deliberately** where a later full refresh will correct it, and write down that decision — an acknowledged staleness window is very different from an accidental one. ## Recognising when appending is the right rule Appending is right when the sources are **phases** rather than **inputs**: a warm-up followed by steady state, a page of history followed by the next page, a required source followed by an optional extension. It is wrong whenever the later sources are producing values independently of you *now*, because then "later" means "after the losses".

  • The first source fails halfway through. Does the second source still run?
    No. A failure is propagated downstream and the later subscription is never created, so appending is not a fallback mechanism. Building one requires a rule that reacts to the failure signal by switching to an alternative source, which is a recovery concern rather than a combining rule.
  • How do you append a stored snapshot before a live feed without losing updates?
    Close the window. Either subscribe to the live feed first and buffer its values until the snapshot has been emitted, or record a position before taking the snapshot and have the feed replay from there. Both make the overlap explicit instead of leaving it to whichever finishes first.

saying these in an interview costs you the question

  • Says both sources are subscribed at the same time
  • Thinks the second source runs when the first one fails
  • Believes a live second source replays what it produced earlier
  • Assumes appending an endless first source still reaches the second
  • Treats appending as a fallback or retry mechanism