Skip to content

Delivery Acknowledgement

Acknowledgement protocol — instantiates Topic-Brokered Event Distribution

A per-message confirmation handshake in which the broker holds an event as delivered only once the consumer acks — redelivering on silence to make at-least-once real.

Delivery Acknowledgement is the handshake that turns "I sent it" into "it was received and handled." After the broker hands an event to a consumer, the event is not considered done: it stays pending until the consumer sends back an ack. If the ack never arrives — the consumer crashed, the network dropped, processing failed — the broker redelivers. Its distinguishing role is to enforce the delivery guarantee at runtime: it is the specific mechanism that makes at-least-once true, by refusing to forget a message until someone confirms responsibility for it. This is what obliges each subscriber to a handler contract — you must ack only after you have durably handled an event, and you must expect that a redelivery can arrive, so your handler had better be idempotent.

Example

A parcel carrier streams scan.events to a tracking service that must update every package's status. The broker delivers a scan; the tracking service writes the update to its database and only then acks. Suppose the service crashes after writing but before acking. The broker, having seen no ack, redelivers the same scan when the service restarts — and the service, applying it a second time, must not double-count the scan or corrupt the record.

So the handler is written to be idempotent: it keys each update by scan id and treats a repeat as a no-op. Now the contract holds cleanly. Every scan is guaranteed to be applied at least once (nothing is lost to a crash), and idempotency neutralizes the duplicates that at-least-once necessarily brings. The ack is the single bit that closes the loop between broker and consumer and decides whether an event is truly finished.

How it works

  • Deliver, then wait. The broker marks an event in-flight and starts a clock; it is not released until acked.
  • Ack after durable handling. The consumer sends the ack only once it has actually processed the event to a durable state — an ack means "I own this now," not "I received the bytes."
  • Redeliver on silence or nack. A missing ack within the timeout, or an explicit negative ack, causes redelivery — the runtime realization of at-least-once.
  • Demand idempotency. Because redelivery can duplicate an event, the handler contract requires processing to be safe to repeat; the protocol supplies the guarantee, the handler supplies the duplicate-tolerance.

Tuning parameters

  • Ack timeout — how long the broker waits before redelivering. Too short redelivers events still being processed (spurious duplicates); too long delays recovery from a genuinely dead consumer.
  • Ack mode — per-message versus batched/cumulative acknowledgement. Batching is cheaper but redelivers more work when a member dies mid-batch.
  • Auto- vs. manual ack — ack on receipt (fast, but loses events if processing then fails) versus ack after processing (safe, the real at-least-once posture).
  • Redelivery limit — how many attempts before the event is diverted rather than retried forever — the hand-off point to a dead-letter path.
  • Delivery guarantee target — at-most-once (no redelivery), at-least-once (redeliver until acked), or exactly-once-effect (at-least-once plus idempotency/dedup). Stronger guarantees cost latency and bookkeeping.

When it helps, and when it misleads

Its strength is that it makes loss visible and recoverable: an event that isn't confirmed isn't forgotten, so consumer crashes and network blips degrade to retries rather than gaps. Paired with an idempotent consumer[1], it delivers the effect most systems actually want — every event handled, duplicates harmless.

It misleads when the duplicate side of at-least-once is ignored. At-least-once guarantees duplicates under failure; a handler that isn't idempotent will double-charge, double-ship, or double-count exactly when things are already going wrong. Auto-ack on receipt quietly downgrades the guarantee to at-most-once while looking reliable in tests. And chasing true "exactly-once delivery" as if the network allowed it wastes effort better spent making handlers idempotent so exactly-once effect is achievable. The discipline is to ack only after durable handling, make every handler safe to repeat, and set the ack timeout and redelivery limit from real processing times rather than defaults.

How it implements the components

  • subscriber_handler_contract — it defines the consumer's obligations: ack only after durable handling, tolerate redelivery, and be idempotent. The contract is what the ack protocol enforces on each subscriber.
  • fan_out_delivery_semantics — it realizes the guarantee half of the delivery contract at runtime, converting a chosen mode (notably at-least-once) into concrete ack-and-redeliver behavior.

It does not decide the fan-out topology or which subscribers get a copy (Fan-Out Exchange), store unacknowledged events durably for an offline consumer (Durable Subscription Queue), decide where retry-exhausted events go (Dead-Letter Queue), or assign partitions across a scaled subscriber (Consumer Group).

References

[1] An idempotent consumer (idempotent receiver) is one for which processing the same message more than once has the same effect as processing it once. Idempotency is the standard companion to at-least-once delivery: the protocol guarantees no loss but permits duplicates, and idempotency makes those duplicates harmless. ↩