skip to content

Transient Fan-Out

8 roadmaps5 questions

Delivering to whoever is connected right now with nothing kept, against a short-lived queue that holds work until someone takes it - and the point where the job has earned a broker.

on this pageshow

explore

questions

5

A price feed is broadcast to recipients attached to a shared volatile tier; one drops for two seconds — what does it receive on reconnect?

level: juniorimportance: must knowfreq 74%

answer

  1. delivery to connections, not storage
  2. whoever is attached at that instant
  3. nothing kept for an absent recipient
  4. at-most-once, no retry, no catch-up
  5. the gap is invisible on both sides

basics

~20 s

Nothing from those two seconds. A broadcast reaches only the connections attached at the instant it is sent, and is then forgotten, so the reconnecting recipient starts from the next message — and neither side can tell a gap happened.

solid answer

~40 s

The broadcast surface delivers to connections; it does not store anything. When the sender hands the store a message, the store copies it to whoever is attached to that name right then and forgets it — there is no entry, so there is nothing to keep for someone who is absent. That makes it at-most-once: attached and healthy means one copy, absent means nothing, then or ever. Reconnecting registers interest from now on, not a resume point, so the recipient receives only what is sent after it is back. The sharp part is that the loss is silent on both sides: the sender's send succeeded, and the recipient has no position or sequence it could compare against to notice the hole.

go deeper

for a junior

Recall the one-line model: the message goes to whoever is attached at that moment and is then gone. Nothing is stored, so there is nothing to collect later.

for a middle

Explain why no entry exists at all, and therefore why lifetimes, memory pressure and restarts are beside the point here. Say plainly that delivery is at-most-once.

for a senior

Demonstrate that you worry about detection, not just loss: the sender's send succeeded, the recipient sees a healthy connection, and only an application-carried sequence or a re-read of the source of record makes the hole visible.

for a principal

Frame it as a requirements question. Decide what a missed message costs the business, and if the answer is anything real, say that the workload belongs on a durable log rather than asking this tier to grow retention.

## What a broadcast on this tier actually promises A broadcast on a shared volatile tier is a **delivery to connections**, not a write to storage. When a sender hands the store a message for a name, the store looks at the set of recipients attached to that name **at that instant**, hands each of them a copy, and forgets the message. No entry is created. There is nothing to attach a lifetime to, nothing that removal under memory pressure could take away later, and nothing a restart could lose — because nothing was kept in the first place. That makes the delivery **at-most-once**: a recipient attached and healthy at the moment of the send receives one copy, and a recipient that is not attached receives nothing, then or ever. The two seconds in the question are two seconds of messages that no longer exist anywhere in the tier, so the reconnecting recipient receives only what is sent **after** it is attached again. ## Why neither side can tell The expensive property of this workload is not the loss; it is that the loss is silent in both directions. - **The sender sees a successful send.** Some stores report how many attached recipients the message was handed to, others report nothing useful, but none of them report whether a *particular* recipient was among them. A message that reached nobody at all is an ordinary successful send, not an error. - **The recipient sees a healthy connection.** Messages arrive with no position, no sequence and no gap marker unless the application put one into the payload itself, so there is no question the recipient can ask the tier that means "what did I miss?" - **Reconnecting is not resuming.** Attaching again registers interest from now on. The tier holds no record that this recipient ever existed, so there is nothing for it to resume from. That is the loss consequence which defines this workload: **a message nobody receives and nobody can discover was missed.** ## Transient fan-out against a durable log | Question | Broadcast on the volatile tier | Durable log behind a broker | |---|---|---| | Kept for an absent recipient | Nothing at all | Retained for a chosen span | | Can a returning recipient catch up | No — it starts from now | Yes, from a recorded position | | Does anyone learn a message was missed | No, on either side | Yes, the gap is visible | | Cost when the tier restarts | Only what was in flight | The retained history survives | The right reading of that table is not "the tier is worse". The two surfaces answer different questions, and the moment a requirement of yours appears in the right-hand column, the workload has left this tier. ## What genuinely varies between stores - **Some stores of this class offer no broadcast surface at all.** A design that assumes one is not portable across the family; if the store you are given has none, the fan-out has to live somewhere else entirely. - Stores that do offer one differ in **what a send reports back**, in whether a recipient may attach to a pattern of names rather than one exact name, and in what the server does with a recipient that cannot keep up. - A store that *also* offers a retained log is offering a **different surface with different promises**. Choosing that surface is choosing the semantics of a broker; it is not a better broadcast. ## How to use it without being surprised 1. **Price a missed message.** "A live chart refreshes a second late" costs nothing; "the customer never learns their payment failed" is unacceptable, and the second one was never a job for this surface. 2. **If the miss is unacceptable, move the workload.** Anything that must be kept for an absent recipient, acknowledged by that recipient, positioned or replayed belongs on a durable log behind a broker. Building retention out of ordinary entries on this tier reproduces a broker badly, on storage that can drop it under pressure or a restart. 3. **If the miss is acceptable, make it self-healing.** Treat the broadcast as a *hint* that the truth changed, keep the truth in the durable source of record, and have the recipient read that source when it attaches and on every reconnect. A missed message then costs latency, not correctness. A junior answer stops at "it receives nothing". The answer that lands adds *why nobody can find out*, and what that forces the design to do about it.

  • The recipient reconnects within milliseconds because the client library reconnects automatically. Does that change the answer?
    No. The gap is measured in messages, not in wall-clock time: anything sent while the connection was down was handed to whoever was attached then and forgotten. A fast reconnect narrows the hole, it does not close it, and the recipient still has no way to learn what fell into it.
  • How could the recipient at least detect that it missed something?
    By carrying a sequence number in the message payload that the sender increments, so a jump in the received sequence tells the recipient to re-read the source of record. That sequence is the application's, not the tier's — the tier tracks no position for anyone — and it turns a silent miss into a detectable one.
  • Does giving the key an entry lifetime, or raising the memory ceiling, change what a disconnected recipient gets?
    Neither is relevant, because no entry exists. A broadcast creates nothing in the keyspace, so there is nothing for a lifetime to expire and nothing for memory pressure to remove. The only memory involved is the undelivered bytes the server holds briefly per attached recipient while it writes them out.

It is a spoken announcement in a departure hall. Everyone standing there hears it once; someone who stepped outside hears nothing, nothing repeats it, and no register exists of who was in the room — so neither the announcer nor the traveller ever learns that one of them missed it.

saying these in an interview costs you the question

  • Assuming the store replays missed messages once the recipient attaches again
  • Believing a reconnect includes a catch-up of what was sent while away
  • Thinking a send that reached nobody comes back to the sender as an error
  • Expecting an entry lifetime or a bigger memory ceiling to change what a broadcast delivers
  • Assuming every in-memory store of this class offers a broadcast surface
  • Treating the tier as the system of record for something the recipient may miss
open as a page

A worker takes an item from a short-lived work channel on the volatile tier and dies mid-job — what happens to that item?

level: middleimportance: must knowfreq 58%

basics

~20 s

It is gone. The take removed it and the store keeps no record that it was handed out, so no acknowledgement is owed and none is missing — nothing in the system can detect that the work was never finished.

open as a page

Which requirements tell you a fan-out workload has outgrown the volatile tier's broadcast and belongs on a durable log with a broker?

level: seniorimportance: must knowfreq 56%

basics

~20 s

Four: something must be kept for a recipient absent at send time; someone must know a recipient handled it; a recipient needs a resumable position; or history must be replayable. Any one means a broker.

open as a page

A recipient attached to the store's broadcast surface reads slower than messages are sent — where does the undelivered backlog sit, and what ends it?

level: seniorimportance: should knowfreq 46%

basics

~20 s

On the server, in the delivery queue the store holds for that recipient's connection, drawing on the same memory as the data. Stores that bound those bytes close the slow recipient's connection: the tier is protected, the recipient sacrificed.

open as a page

Your operations console keeps panes live via transient fan-out on the volatile tier and you will not add a broker — how do you design so a missed message is a named degradation rather than a wrong screen?

level: principalimportance: should knowfreq 40%

basics

~20 s

Make the broadcast a hint, never the truth. Panes read state from the durable source of record on attach, on reconnect and on a periodic refresh; the broadcast only says read sooner. The miss then costs bounded staleness you can state.

open as a page