Queue delivery guarantees: acknowledgments, redelivery and effects
Trace queue delivery from publication to acknowledgment. Explain redelivery, visibility timeouts and why reliable delivery still requires idempotent business effects.
TL;DR: A delivery guarantee covers a defined boundary. A broker accepting a message, a consumer receiving it and a business effect committing are separate events; design recovery for the uncertain gaps between them.
Two acknowledgments answer different questions
A publisher confirmation tells the producer about the broker's handling of a publication. A consumer acknowledgment tells the broker that a delivered message can be considered handled. Neither acknowledgment alone proves every downstream effect completed. RabbitMQ explicitly separates publisher confirms and consumer acknowledgments; applications must choose the durability and acknowledgment settings appropriate to their queue type and failure model.
With early acknowledgment, the broker may remove a message before the application commits its work. A crash in that gap can lose the effect. With acknowledgment after commit, a crash after the commit but before the acknowledgment can cause redelivery. Moving the acknowledgment changes the failure window; it does not make both windows disappear.
The second path back to Ready is why a redelivered message must remain safe even when the previous handler appeared to succeed. The broker's delivery state cannot read your application's transaction history.
Work through the crash boundary
Imagine a warehouse service consuming an illustrative ReserveInventory event. It updates a database row and then acknowledges the message. The process terminates between those actions. The reservation exists, but the queue makes the message available again. Reapplying an unconditional decrement would reserve the same inventory twice.
Use a stable operation identity and commit the duplicate-detection record with the local inventory change in one transaction. A second attempt finds that identity and returns the previously established outcome without repeating the effect. A temporary in-memory set cannot survive the consumer crash, and an independently committed deduplication row can hide work that never completed. Idempotency explains that local effect boundary; outbox and inbox transactions extend the design across publication and consumption.
| Crash or uncertainty | Queue may do | Application responsibility |
|---|---|---|
| Before producer knows publication succeeded | Producer may retry publication | Preserve the operation identity |
| Before consumer commits | Deliver again | Allow the incomplete operation to retry |
| After commit, before acknowledgment | Deliver again | Recognize the committed operation |
| During an external API call | Deliver again with outcome unknown | Reconcile or use the provider's idempotency contract |
“Exactly once” is useful only with the system and effects it covers named explicitly. A transactional broker feature may coordinate its own records while an email or payment API remains outside that transaction. Do not extend a product's guarantee to a side effect it does not own.
Visibility is a lease on an attempt
Amazon SQS uses a visibility timeout: a received message becomes temporarily unavailable to other consumers, and deletion marks successful handling. If it is not deleted in time, it can become visible again. An extension gives a worker more time, but it does not prove that worker is healthy or prevent every duplicate under an at-least-once service contract. See SQS visibility behavior.
Suppose normal work takes 20 seconds and the timeout is 30 seconds. A dependency slowdown stretches one attempt to 45 seconds. A second worker can receive the message while the first is still processing it. Extending the timeout reduces avoidable overlap, while durable idempotency handles overlap that still occurs. A very long timeout has a cost: after a dead worker, recovery may wait longer. Choose it from measured processing behavior and use a bounded extension policy, rather than assuming the maximum is safest.
Kafka records completion differently. Partitions, consumer groups and offsets explains which offset a consumer can commit after partially completing a batch.
Retries need an exit
A malformed event can fail deterministically forever. Bound attempts, preserve the payload and failure context, and send exhausted work to an owned recovery path. A dead-letter queue needs alerting on age and volume, a diagnosis procedure and a controlled replay method. Replaying every failed message at once can recreate the original overload. Keep the operation identity during replay unless a reviewed business decision intentionally creates a new operation.
An interview answer should also state the retention boundary. If the deduplication record expires before an old message can be replayed, the replay may repeat an effect. Align deduplication retention with the replay contract, or reconcile old operations before allowing them back into normal processing.
Self-check: a consumer logs “success,” crashes, and receives the same event again. Is the duplicate evidence of a broken queue? No. The log might precede a commit, and an acknowledgment might never have reached the broker. Inspect the durable business record and operation identity first. A retry should complete missing work or recognize completed work without guessing from a log line.