When responsibility transfers

At what exact moment does a message stop being the sender's problem?

A service publishes an event and moves on. Somewhere downstream another service consumes it. Between those two sentences there is a moment when the message stopped being the first service's concern and became the second's — and almost nobody can name it.

Try to name it and the candidates multiply: when the bytes left the socket? When the broker replied? When the consumer received it? When the work finished? They cannot all be right, and picking the wrong one is how a system quietly loses work while every component reports success.

Begin by asking what "being responsible" for a message even consists of. Strip away the intuition of possession and one operational fact remains: the responsible party is the one who will send it again if it vanishes. That is the whole content of the idea. Responsibility is not about who holds a copy — during a handover both parties hold copies — it is about who still has a retry obligation.

That reframing makes the moment findable. Responsibility transfers at the instant the previous holder decides it will never retry. Which means it is not a physical event at all. It is a policy event, chosen by whoever wrote the acknowledgement logic, and it can be placed anywhere along the path.

Now trace the path with that lens. A producer sends a record and holds its retry obligation until the broker acknowledges. What that acknowledgement means is itself configurable, and the differences are not cosmetic: an acknowledgement from the leader alone means the record survives everything except that leader failing, while waiting for all in-sync replicas means it survives one machine's loss. Worth noting honestly: Kafka's durability here comes from replication across machines rather than from forcing every write to disk before replying, so a simultaneous power loss across the replica set is outside the guarantee.

Then the broker holds it. And the broker's obligation ends only when the consumer says so — which is the second transfer and the one people get wrong. AMQP 1.0 has the best word for it: settlement. A delivery is unsettled while either party might still act on it, and each side declares independently when it has settled. Kafka expresses the same thing as an offset commit; SQS expresses it as deleting the message before its visibility timeout expires; a classic broker expresses it as an explicit ack or nack.

Here is the question that exposes the design. In each of those, is the settlement sent before or after the work is done? If a client library acknowledges on receipt — which several do by default — then responsibility transferred at the moment of arrival, and a crash one millisecond later destroys the message with the job untouched. Nothing logs an error, because from the broker's view the handover succeeded.

And notice why duplicates exist. Between "the consumer settles" and "the broker learns it settled" there is a window where both believe they may be responsible. The broker cannot tell a consumer that crashed before finishing from one that finished and whose commit was lost, so it redelivers. Shrink that window to nothing by settling earlier and you have not removed the ambiguity — you have converted the duplicate into a loss.

One more layer, easy to miss. There is also responsibility toward the outside world. If your API told a caller "accepted" before the broker acknowledged, then you took on an obligation the system may not be able to keep, and the caller has no way to find out. The API response belongs after the broker's acknowledgement, not before it.

The refinement that ties it together: an unbroken chain of overlapping responsibility is the property you actually want. At no point should there be an instant where nobody would retry. Auto-acknowledgement breaks the chain by ending one obligation before the next begins. Settling after the work, with an identifier that lets a repeat be recognized, deliberately overlaps the obligations instead — which is why at-least-once and deduplication travel together.

A misconception worth naming: that a dead-letter queue is a failure handler. It is better understood as the broker's declaration that it is giving up its own obligation, because the redelivery loop is not converging. That makes it a transfer too — to a human, or to a process that has to decide what an unprocessable message means. A dead-letter queue nobody reads is a chain that ends in nothing.

And one genuine subtlety: settling does not mean the work's effects are visible. A consumer can commit its offset while its own database write is still in flight. The transfer of responsibility must be tied to the durability of the effect, not to the completion of the handler function, or the chain is broken inside your own process.

• How AMQP 1.0's settlement modes let each side declare its own moment, and what the unsettled state buys you.
• Why a visibility timeout is really a lease on responsibility, and what happens when the work outlives the lease.

Every term the collection defines is gathered in the glossary.