Dead-letter queue
A dead-letter queue holds messages set aside for investigation and controlled reprocessing.
A dead-letter queue (DLQ) is a separate queue for messages set aside from normal processing. It makes unprocessed messages available for investigation and controlled reprocessing. Configuration determines which messages reach it; not every application error automatically routes a message there.
Setting messages aside needs a recovery path
In a fictional integration system, message E-81 contains an unsupported schema version. Instead of being retried endlessly in the normal flow, it follows the configured failure route. The team records the failure reason and message identity so they remain traceable. After correcting the data or adapting the consumer, it can deliberately reprocess the message while preventing duplicate effects.
In RabbitMQ, the Dead-Letter Exchange (DLX) is the routing point that forwards these messages to bound queues. It is not itself the DLQ. Reasons can include rejection without requeueing, message expiry or configured limits. Routing and suitable queue bindings must be configured.
Monitoring, access rights, retention and a reprocessing procedure are also needed. A DLQ is neither a completed job nor an automatic repair. Forwarding is not a blanket guarantee against loss either: RabbitMQ’s default dead-lettering can lose messages if the destination queue is unavailable.
Sources
Related terms
- Message acknowledgementA message acknowledgement tells the broker that a delivery has been received or processed according to the agreed rule.
- Transactional inboxA transactional inbox uses durable message records to protect local processing against duplicate deliveries.
- Retry strategyA retry strategy defines which failures to retry, the waiting intervals and the limit on further attempts.
- Server-sent eventsServer-sent events carry text notifications from server to client over HTTP, for example about the progress of a background job.
- Entity tagAn ETag identifies a particular representation version of an HTTP resource and supports conditional reads or changes.
- Cross-Origin Resource SharingCORS controls browser access to responses across origin boundaries. It replaces neither API login nor permission checks.
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.