Dead-letter queue (DLQ)
A queue that receives messages a consumer failed to process after retries, isolating poison messages for inspection. It prevents infinite redelivery loops. Essential for at-least-once systems.
- Any at-least-once consumer.
- Isolating poison messages for manual handling.
- As a substitute for fixing the consumer.
- When you can't tolerate any message loss (replay, don't drop).
Definition
A DLQ is a separate queue where messages that exceed a retry threshold or TTL are sent. Operators inspect and replay or discard them. Without a DLQ, poison messages redeliver forever, blocking progress.
Why it exists
At-least-once delivery redelivers failures; a message that always fails would loop forever, blocking the queue. A DLQ parks it so the main queue keeps flowing and humans can investigate.
How it works
After N failed attempts (or a max-receive count), the broker moves the message to the DLQ. SQS uses a redrive policy; Kafka needs app-level DLQ topics. You monitor DLQ depth and replay fixed messages or drop them.
Scaling limits
DLQs don't fix the bug; they isolate it. Without monitoring, DLQs silently accumulate. Replay logic must handle the original ordering/fan-out.
Cost shape
Storage for parked messages. Blow-ups: unmonitored DLQ growth and repeated replays of unfixed messages.
Alternatives
- Infinite retry with backoff — No loss but blocks the queue on poison messages.
- Drop on failure — Simplest but loses data.
Failure modes
- DLQ filling unmonitored.
- Replaying without fixing the root cause.
- Losing ordering on the way to DLQ.