RabbitMQ dead lettering: make poison-message transfer observable and recoverable

Last updated: 7 Oct 20267 min read

tutorial

RabbitMQ can dead-letter messages after a rejection without requeue, expiration, queue-length action, or a delivery-limit event, depending on queue type and policy. The source queue republishes to a dead-letter exchange; an absent binding or unavailable target can make the transfer unsafe under ordinary at-most-once behavior. Quorum queues offer an at-least-once dead-letter strategy when its required policy settings are present, including reject-publish overflow. That strategy retains source messages until target confirmation, but adds internal consumer work and can occupy source queue capacity. A dead-letter queue is useful only when its owner can diagnose, repair, and safely replay the event.

Operational decision

A settlement decoder rejects a malformed event after a bounded number of attempts. The source quorum queue sends it to a durable quarantine queue through an explicitly bound dead-letter exchange; the original publish uses persistent delivery mode so the target can retain it through a restart. The operator injects a missing target binding and confirms that the source does not silently lose the event under the chosen strategy. They then restore the binding, check the transfer receipt, and replay after repairing the decoder. The replay tool preserves the original business event ID, records the reason and count of previous attempts, and throttles its publish rate. Rejecting every event immediately back to the same source would form an expensive redelivery loop instead of a repair workflow.

Source: settlement-work quorum queue
Failure: bounded delivery attempts exhausted
Dead-letter exchange: settlement-failures
Target: settlement-quarantine, durable and bound
Transfer policy: at-least-once with reject-publish overflow
Replay: preserve business ID and cap release rate

Cost and verification

At-least-once transfer uses additional CPU and memory and may retain dead letters in the source while the destination is blocked. A queue-length cap and overflow policy must be reviewed together; switching to drop-head can remove the transfer guarantee and strand an unconfirmed handoff. Monitor source depth, dead-letter consumer backlog, target confirms, and quarantine age. Before changing a live policy, rehearse a missing binding and target outage. Never assume a dead-letter exchange is a lossless archive merely because the queue name exists in a dashboard.

Common Mistakes

Do not send poison messages back to the same hot queue indefinitely.
Do not call a dead-letter transfer safe without checking target routing and confirms.
Do not switch overflow policy without reviewing the at-least-once transfer contract.

Connected lessons

Practice and check

devops

rabbitmq

queue-operations