A worker takes an item from a short-lived work channel on the volatile tier and dies mid-job — what happens to that item?
answer
- the take is the whole transaction
- nothing records who took it
- no acknowledgement owed, none missing
- a drained backlog looks the same either way
- parking the item is the only local recovery
basics
~20 sIt 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.
solid answer
~50 sA short-lived work channel on this tier holds an item until exactly one taker removes it; a taker may use a blocking take, a read that waits on the server until an item arrives or the wait expires. Removal is the whole transaction. The store does not record who took the item, does not expect it back, and has no timer that returns it — so a worker that dies between taking and finishing destroys the item silently. That is the difference from a broker: there, an item stays owned until it is acknowledged, and an unacknowledged item comes back. Some stores in this class offer a take that atomically places the item in a second holding place, which is the only recovery this tier gives you: a sweeper can find items parked too long and return them, blindly, so the workload degrades to at-least-once. Stores without that leave you nothing to sweep.
go deeper
Remember that taking an item removes it. Once it is out of the store, the store has no copy and no memory of who took it, so a worker that dies takes the item with it.
Explain why nothing detects the loss: no acknowledgement is owed, so none can be missing, and an emptied channel looks identical whether the work finished or vanished.
Show the design reflex: keep the authoritative job state in a durable store so the channel only carries a nudge, and say plainly that any recovery available here redelivers blindly and must be safe to repeat.
Decide per workload whether losing an in-flight item is a delay or a broken promise, and move the second kind onto a broker instead of accumulating ownership machinery on a volatile tier.
## What a take actually does A short-lived work channel on a shared volatile tier is a place where senders put items and takers remove them. Two properties define it, and both differ from the broadcast on the same tier: - An item **waits** until someone removes it, rather than being delivered to whoever happens to be attached at that instant. - Exactly **one** taker gets a given item, because taking it removes it. A taker usually waits with a **blocking take** — a read that waits on the server until an item arrives or the wait expires — rather than asking repeatedly in a loop. That is a handoff shape, and what matters for this question is what the take leaves behind: **nothing**. The item is out of the store. The store did not record who took it, is not expecting anything back, and is running no timer against it. ## So the item is simply gone When the worker dies after the take and before the work is finished, there is no state anywhere that says the work was owed. Trace what each party knows: | Party | What it knows after the worker dies | |---|---| | The store | That the channel has one fewer item. Nothing about who took it or whether it finished | | The sender | That its item was accepted. It was never told about completion, so it detects nothing | | Another worker | Nothing at all — the item is not visible to it, because it no longer exists | | An operator | Only what the application logged before the worker died | This is the leaf's loss consequence in its work-handoff form: not merely that work is lost, but that **nobody can discover it was lost**. A backlog that drains to empty looks identical whether every item was completed or half of them evaporated. ## Why a broker is different What a durable log behind a broker adds is exactly the state this tier declines to keep: the item stays owned by the taker until the taker says it is done, and an item that is never acknowledged becomes visible again. Retention, acknowledgement, reader positions and replay are that neighbour's subject, and the useful thing to say in an interview is the *boundary*: the moment your workload needs an item to survive a worker that never comes back, you are describing a broker, and you should reach for one rather than grow one out of ordinary entries here. ## What genuinely varies between stores - **Some stores offer a take that atomically parks the item in a second holding place** instead of only removing it. The item is then still visible, and a sweeper can return items that have sat there too long to the main channel. - **Many stores offer nothing of the kind** — either no such move, or no server-understood collection to hold items in at all, in which case the workload cannot be built this way. - **What the return costs you**: a sweeper cannot know whether the missing worker finished the side effect before dying, so returning the item redelivers it blindly. The workload **degrades to at-least-once**, and the work must be safe to do twice. ## How to decide what to build 1. **Ask whether the item is re-derivable.** If the work can be rebuilt from a durable source — a row whose status is still `pending`, a file still in a folder — losing the in-flight item costs a delay, not data, and a plain work channel is fine. 2. **Ask what a lost item costs.** "One thumbnail is not generated until the nightly sweep" is a cost you can carry; "one customer's refund is never issued" is not, and that workload needed a broker before it needed tuning. 3. **Ask whether the work is safe to repeat.** Any recovery available here redelivers blindly, so if repeating is unsafe the guard has to be somewhere else, downstream of this tier. 4. **Do not confuse the channel with the record.** Keeping the authoritative state of the job in a durable store and using the channel only to say "there is a job" makes both the loss and the recovery boring. The answer that marks a middle engineer is the flat statement that the item is gone and nothing notices — followed by where the recovery would have to live if the item mattered.
- How does this differ from a broadcast on the same tier?A broadcast is delivered to every recipient attached at that instant and kept for nobody; an item in a work channel waits until exactly one taker removes it. The losses differ too: a broadcast is missed by whoever was absent, while a channel item is lost only if its one taker fails after removing it.
- A sweeper returns items that have sat in the holding place too long. What have you actually built?Blind redelivery. The sweeper cannot tell whether the vanished worker completed the side effect first, so the work may run twice and the workload degrades to at-least-once. That is acceptable when repeating is harmless, and when it is not, the real guard has to sit downstream of this tier.
- Why not keep the item in the channel until the worker reports success, instead of removing it on take?Because the store has no notion of an item being owned but not yet removed — leaving it in place makes it visible to every other taker at once. Reproducing ownership would mean tracking takers, deadlines and acknowledgements on this tier, which is building a broker on storage that can drop it.
saying these in an interview costs you the question
- Expecting the store to return an item whose taker never finished
- Believing a take is reversed if the connection drops
- Assuming an emptied work channel means all the work was completed
- Thinking blind redelivery restores exactly-once behaviour
- Assuming every store of this class can hold a work channel at all