Exhaust the bounded retry or validation path and decide that normal processing cannot continue safely.
Enterprise Messaging · Messaging Channels
Dead Letter Channel
Move undeliverable messages to a separate channel that preserves failure context and supports investigation, repair and controlled replay.
What will the messaging system do with a message it cannot deliver?Adapted from Enterprise Integration Patterns under CC BY 3.0. The visualization and explanatory content on this page are original GateSift material.
Original GateSift visualization
How Dead Letter Channel works
Messages that cannot be processed safely after normal retry are isolated with diagnostic context instead of blocking or disappearing from the main flow.
Failed message
Classify final failure
Main flow
Dead-letter
Move the message to a durable failure channel with correlation, reason and useful operational metadata.
Investigate, repair and replay through a controlled process that protects against duplicate side effects.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use a dead-letter path to isolate messages that cannot be processed safely after normal retry or validation handling, while preserving enough evidence for diagnosis and recovery.
- Poison messages must not block the main processing path.
- Operators need a durable place to inspect and replay failed messages.
- The system can distinguish terminal failure from a transient error that should still be retried.
- The failure can be handled synchronously and returned directly to the caller.
- Messages are sent to dead-letter immediately for errors that are clearly transient.
- No operational process exists to monitor, diagnose and drain the dead-letter backlog.
Dead-letter graveyardHigh impact
A DLQ without ownership, alerts and replay procedures becomes hidden data loss.
Replay duplicationHigh impact
Reprocessing failed messages can repeat completed side effects unless handlers are idempotent.
Sensitive payload retentionReview
Failure payloads may contain secrets or personal data and need the same retention controls as production messages.
- Service Bus queues and subscriptions provide built-in dead-letter subqueues with reason and description metadata.
- Capture correlation identifiers, delivery count and a concise failure reason before replay tooling changes the message context.
- Alert on backlog age as well as count; a small number of old dead-lettered messages can still represent an unresolved incident.
What this pattern helps you decide
Move undeliverable messages to a separate channel that preserves failure context and supports investigation, repair and controlled replay.
What exact conditions move a message to dead-letter instead of retrying it?
Who owns replay and how is duplicate business processing prevented?
Are dead-letter age, count and repeated failure reasons observable?
Where you may see it
- Azure Service Bus DLQ
- Storage Queue poison queue
- Logic Apps dead-letter workflow
How the analyzers can surface it
- Missing failure routes
- Retry and terminal-error handling
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
GateSift support
Where GateSift can surface this pattern
Detection means the source contains direct structural evidence. Signal means the analyzer sees compatible structure but still needs architectural context.
Source, licence and attribution
The pattern name and selected problem statement are adapted from Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf under CC BY 3.0. GateSift summaries, Azure mappings, analyzer guidance and diagrams are original. No endorsement by the original authors is implied.