Dead Letter Queues (DLQ)

In an event-driven system, some messages will simply never succeed (e.g., a "Poison Message" with invalid JSON). If you keep retrying forever, you block the queue. A Dead Letter Queue is the "Trash Can" for messages that have failed all retry attempts.

1. Why use a DLQ?

Instead of losing the data, the broker moves the failed message to a separate queue (e.g., orders-error). This allows developers to inspect the message, fix the bug, and "Replay" the message back into the main queue later.

2. Poison Messages

A poison message is a message that causes a consumer to crash immediately. Without a DLQ and a retry limit, the message would go back to the top of the queue, crash the consumer again, and enter a "Death Loop" that consumes 100% CPU forever.

4. Interview Mastery

Q: "Should I trigger an Alert when a message hits a DLQ?"

Architect Answer: "Absolutely. A message in a DLQ is a 'Silent Failure.' The user might be waiting for an email that will never arrive. High-maturity teams set up monitoring (like Prometheus or Azure Alerts) to Ping the developers the moment the DLQ count goes above zero. It is an indicator of a bug in your consumer logic or a schema mismatch between services."