What is a dead letter queue and when do you use one?
A dead letter queue holds messages that failed processing after the allowed retries. It stops one bad message from blocking the queue forever and keeps the message for inspection and later reprocessing.
Explain it simply
A post office sends undeliverable letters to a special room instead of trying forever. A dead letter queue (DLQ) is that room.
Why it is needed: a message may be impossible to process, say malformed JSON or a reference to a deleted user. If the consumer keeps failing and the broker keeps redelivering, that poison message loops forever, wastes workers and can block messages behind it.
Typical setup:
- Consumer fails; the message is retried, maybe with exponential backoff.
- After a maximum number of attempts (say 5), the broker moves it to the DLQ.
- Normal processing continues.
- An engineer is alerted, inspects the DLQ, fixes the bug or data, and redrives the messages to the main queue.
Good practice: alert on DLQ depth, store the error reason and attempt count with the message, and set a retention long enough to investigate. A growing DLQ is a health signal, not a place to forget failures.
Example
Queue: orders
msg 41 fails (null address) -> retry 1,2,3,4,5 all fail
msg 41 moved to orders-dlq
msg 42, 43, 44 continue normally
Alert: orders-dlq depth > 0
Fix validation, then redrive msg 41 back to ordersWhat to say in the interview
"A DLQ captures messages that exceed their retry limit so poison messages do not block healthy traffic. I alert on its depth, keep error context, and provide a way to fix and redrive. It prevents loss without halting the pipeline."