Demystifying Dead Letter Queue
Today I’ve heard the term Dead Letter Queue (DLQ) for the first time in my career. I have been working as a full time software engineer for more than 10 years and still I am amazed by learning new interesting topics each and every day!
DLQ is basically a separate queue that stores the messages in your system where the messages wasn’t processed correctly. There can be various reasons where a message in the system can’t be processed for example:
- an issue on the message sender
- a change in the message receiver application
- state changes during message handling
- queue limit exceeded
- message length limit exceeded etc. The whole list can be seen in [1].
In these circumstances, generally there is a retry mechanism, which enables some of the messages to be processed successfully. However, in some cases even if messages retried couple of times, the messages can’t be handled, in these cases the messages can be stored in a separate queue.
Here is the architecture diagram of the dead letter queue.
Message Sender is sending messages to a channel and Message Receiver expects the delivery. However, when there is an issue with the delivery, the messages don’t get lost, instead they are forwarded to the DLQ. The advantages of setting up a dead letter queue are the following:
- You can setup alerting for messages that forwarded to a dead-letter queue. This way you can quickly see if there is an issue happening on your system.
- Since you are aware of the issue, you can examine the logs for exceptions that resulted in increased number of messages in the DLQ.
- The unprocessed messages are not lost! This can result in building up a retry mechanism for the unprocessed messages when the issues are fixed.
- You can analyse the messages that moved to DLQ to further examination and diagnose issues.
Almost all of the commercial message queue products support DLQ setting. Amazon Simple Queue Service, Rabbit MQ, Apache ActiveMQ, Apache Kafka etc.
