NEW
Also known as: DLQ
A dedicated queue that stores messages that cannot be successfully processed by their original consumers.
DESCRIPTION
A dead letter queue is a safety net for failing messages that exceed retry thresholds or violate processing constraints. It isolates problematic messages (poison messages) to prevent blocking normal flow. Operators inspect DLQs to diagnose errors, correct data, and redrive messages after remediation. DLQs support operational resilience and auditability in asynchronous systems. Proper DLQ design includes clear routing policies, monitoring, alerting, and redrive mechanisms. It’s a standard feature in SQS, Service Bus, Pub/Sub, and RabbitMQ (via dead-letter exchanges).
ALTERNATIVE DEFINITIONS
AWS
A dead-letter queue is a queue that other queues can target for messages that can’t be processed (consumed) successfully.
Defines DLQ as a target for failed messages across queues.
Microsoft Learn
A dead-letter queue (DLQ) is a sub-queue that holds messages that can’t be delivered to any receiver or that couldn’t be processed.
Describes DLQ as a sub-queue and reasons for dead-lettering.
Google Cloud
Dead letter topics let you redirect undeliverable messages to a dead letter topic that you can use for further analysis.
Frames the concept as a topic for undeliverable message analysis in Pub/Sub.
RELATED TERMS
Queue Poison Message At-Least-Once Delivery Visibility Timeout Error Handling Redrive Policy Azure Service Bus AWS SQS
COMPETING TERMS
Retry Queue Retry with Backoff
RELATIONS
- Broader: Queue
KNOWLEDGE AREAS
Real-time & Streaming Data Data Engineering Data Management Testing & Validation
TARGET AUDIENCE
Data Engineer Software Developer DevOps Engineer Cloud Architect Data Architect MLOps Engineer
EXTERNAL SOURCES
- Wikipedia - Dead letter queue
- AWS - SQS DLQ documentation
- Microsoft - Azure Service Bus DLQ
- Google Cloud - Pub/Sub dead letter topics
- RabbitMQ - Dead-letter exchanges in RabbitMQ
TOP QUESTIONS
Why use a Dead Letter Queue?
DLQs prevent stuck pipelines by isolating failed messages. They enable analysis, remediation, and safe redrives without blocking healthy traffic.
Category: Relevancy
What commonly sends messages to a Dead Letter Queue?
Messages exceeding max-delivery attempts, violating size or TTL constraints, or causing repeated processing errors are dead-lettered.
Category: Example
What are the risks of using a Dead Letter Queue?
If unmonitored, DLQs accumulate and hide systemic issues. Blind redrives can cause loops. Sensitive data may need controls.
Category: Risks
How should teams manage a Dead Letter Queue?
Set alerts on message age/size, capture error context, and define clear redrive procedures. Automate triage where possible.
Category: Management
What is a common misunderstanding about Dead Letter Queues?
DLQs don’t fix errors automatically; they surface them. You still need root-cause analysis and remediation.
Category: Misunderstanding
What competes with Dead Letter Queues?
Retry queues and backoff strategies reduce dead-lettering. Transactional outbox and idempotency also mitigate failures.
Category: Alternatives
How do you secure a Dead Letter Queue?
Restrict access, scrub sensitive payloads, audit reads, and encrypt at rest and in transit.
Category: Requirements
How to avoid filling the Dead Letter Queue?
Set backoff and max retry limits, validate inputs early, and implement circuit breakers for failing dependencies.
Category: Advice
What metrics matter for Dead Letter Queues?
Message age, inflow rate, redrive success, and error categories help prioritize remediation.
Category: Requirements