# What is a dead-letter queue? ![rw-book-cover](https://a0.awsstatic.com/libra-css/images/logos/aws_logo_smile_1200x630.png) ## Metadata - Author: [[Amazon Web Services, Inc.]] - Full Title: What is a dead-letter queue? - Category: #articles - Summary: A dead-letter queue (DLQ) is a special queue that stores messages a system cannot process due to errors. It helps prevent message pile-up and makes troubleshooting easier by isolating problem messages. Developers use DLQs to fix issues and keep the main system running smoothly. - URL: https://aws.amazon.com/what-is/dead-letter-queue/ ## Highlights - A dead-letter queue (DLQ) is a special type of message queue that temporarily stores messages that a software system cannot process due to errors. ([View Highlight](https://read.readwise.io/read/01ktwrmppvxt1cveycd0vev6de)) - They let you send messages between software services at any volume and don’t require the message receiver to always be available. A dead-letter queue specifically stores erroneous messages that have no destination or which can’t be processed by the intended receiver. ([View Highlight](https://read.readwise.io/read/01ktwrp7abm46kfaj9avcvsx1a)) - There are two potential causes when messages move to the DLQ pipeline: erroneous message content and changes in the receiver’s system. **Erroneous message content** A message will move to a DLQ if the transmitted message is erroneous. Hardware, software, and network conditions might corrupt the sent data. For example, hardware interference slightly changes some of the information during transmission. The unexpected data corruption could cause the receiver to reject or ignore the message. **Changes in the receiver’s system** A message might also move to a DLQ if the receiving software has gone through changes that the sender is not aware of. For example, you could attempt to update a customer's information by sending a message for *CUST_ID_005*. However, the receiver could fail to process the incoming message because it’s removed the customer from the system's database. ([View Highlight](https://read.readwise.io/read/01ktwrqzktvddg5pfy6kjadm95)) - Next, we talk about the benefits of dead-letter queues (DLQ). **Reduced communication costs** Regular or standard message queues keep processing messages until the retention period expires. This helps ensure continuous message processing and minimizes the chances of your queue being blocked. However, if your system processes thousands of messages, a large number of error messages will increase communication overhead costs and burden the communication system. Instead of trying to process failing messages until they expire, it’s better to move them to a dead-letter queue after a few processing attempts. ([View Highlight](https://read.readwise.io/read/01ktwse0j8605hawbwpx6gmmmk)) - **Improved troubleshooting** If you move erroneous messages to the DLQ, this lets your developers focus on identifying the causes of the errors. They can investigate why the receiver couldn't process the messages, apply the fixes, and perform new attempts to deliver the messages. For example, a banking software might send thousands of credit card applications daily to its backend system for approval. From there, the backend system receives the applications but cannot process all of them because of incomplete information. Instead of making endless attempts, the software moves the messages to the DLQ until the IT team resolves the problem. This allows the system to process and deliver the remaining messages without performance issues. ([View Highlight](https://read.readwise.io/read/01ktwseh81xh8czh8hgs5ane0z)) - When should you use a dead-letter queue? ([View Highlight](https://read.readwise.io/read/01ktwshfxhcfe2d2v93d6s6jng)) - **Unordered queues** You can take advantage of DLQs when your applications don’t depend on ordering. While DLQs help you troubleshoot incorrect message transmission operations, you should continue to monitor your queues and resend failed messages. ([View Highlight](https://read.readwise.io/read/01ktwshmqgzdfdhtdms7etdy9t)) - **FIFO queues** Message ordering is important in first-in, first-out (FIFO) queues. Every message must be processed before delivering the next message. You can use dead-letter queues with FIFO queues, but your DLQ implementation should be FIFO as well. ([View Highlight](https://read.readwise.io/read/01ktwska4g1x9ygc30k5n607ch)) - You shouldn’t use a dead-letter queue (DLQ) with unordered queues when you want to be able to keep retrying the transmission of a message indefinitely. For example, don’t use a dead-letter queue if your program must wait for a dependent process to become active or available. ([View Highlight](https://read.readwise.io/read/01ktwsmjecnkgvn5c07y9j1kth)) - **Creating a redrive policy**  Software moves messages to a dead-letter queue by referring to the redrive policy. The redrive policy consists of rules that determine when the software should move messages into the dead-letter queue. Mainly by defining the maximum retry count, the redrive policy regulates how the source queue and dead-letter queue interact with each other.  For example, if your developer sets the maximum retry count to one, the system moves all unsuccessful deliveries to the DLQ after a single attempt. Some failed deliveries may be caused by temporary network overload or software issues. This sends many undelivered messages to the DLQ. To get the right balance, developers optimize the maximum retry count to ensure the software performs enough retries before moving messages to the DLQ. ([View Highlight](https://read.readwise.io/read/01ktwsqkswz8dd4s5r4f3qdvde)) - **Moving messages into the dead-letter queue** Delivery attempts between the sender and receiver can fail for several reasons:  • The receiver fails to receive the message because it doesn't exist.  • The message contains errors.  • The message exceeds the queue or message length limits. For example, some receivers can't process messages that exceed a specific size.  • The message's *time to live* (TTL) has expired. TTL is a value that indicates how long a particular data packet is valid on the network. ([View Highlight](https://read.readwise.io/read/01ktwsrrac886kr1xnm90krqp6))