Practice this topic in a realistic system design interview
Retries are useful when a failure might go away on its own. A network timeout, a busy database, or a short service outage is worth retrying.
Some failures are different. A message may have bad data, point to a record that no longer exists, break a business rule, or hit a bug in the consumer. Retrying that message forever wastes worker time and can stop later messages from moving forward.
A dead letter queue (DLQ) is where a messaging system puts messages that failed too many times. It keeps the main queue moving, while saving the failed messages so someone can inspect, fix, replay, or delete them.
The important idea is simple:
A DLQ is not where messages go to be forgotten. It is a holding area for messages that need a decision.
This chapter covers how dead letter queues work, when messages land there, and how to handle them.
A dead letter queue is a separate queue, topic, or stream that receives messages after normal processing has failed too many times. Some brokers also let the consumer send a message to the DLQ directly when retrying would not help.
The exact mechanism depends on the messaging system, but the pattern is the same:
The normal flow is:
This prevents one bad message from using worker capacity forever. In FIFO or ordered systems, it can also prevent a "poison message" from blocking everything behind it. A poison message is a message that fails every time it is processed.