Back to Catalog
Integration
Message Channels
Dead Letter Channel
Messages that cannot be delivered go here — the last stop before permanent failure.
Intent & Description
Real-world Use Case
SQS queue with maxReceiveCount=5. Order processing message fails 5 times (all with the same NullPointerException). On the 5th failure, SQS moves it to the orders-dlq. Engineer gets a PagerDuty alert, fixes the NPE, deploys, and reprocesses the dead-lettered message from DLQ. Order is finally processed.
Source
📌 TL;DR
Dead Letter Channel = where messages go to die (temporarily). Retry limit exhausted → DLQ. Monitor it, fix the bug, reprocess. A DLQ that nobody watches is just a delayed data loss.
Advantages
- Prevents infinite retry loops from blocking the main queue
- Preserves failed messages for analysis and reprocessing
- Clear operational metric — DLQ depth = unresolved failures
- Enables post-fix reprocessing without message loss
Disadvantages
- DLQ messages require manual or automated remediation — they do not fix themselves
- If DLQ is not monitored, silent failure accumulates undetected
- Reprocessing from DLQ requires a workflow (replay, fix-and-resubmit)
- Root cause of dead-lettering must be fixed or the cycle repeats