# Dead Letter Channel

> Messages that cannot be delivered go here — the last stop before permanent failure.

- **Category**: Integration
- **Subcategory**: Message Channels
- **Canonical URL**: https://designpattern.fyi/patterns/dead_letter_channel/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
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.





## Trade-offs


### 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




### Considerations & Drawbacks

- 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







---
**Reference**: [Original Source](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)