Resilient Messaging: The DLQ

What happens when a message is corrupted or causes your code to crash? Without a Dead Letter Queue (DLQ), that message will keep being retried forever, blocking the whole system. This is known as a **Poison Message**.

1. The Retry Policy

A resilient system should:

1. Try to process the message.
2. If it fails, wait 30 seconds and try again (Exponential Backoff).
3. After 10 failed attempts, move it to the **DLQ**.

2. Managing the DLQ

The DLQ is like a "Hospital" for messages. They sit there safely without blocking the rest of the queue. Developers can then inspect the messages, fix the bug, and "Re-drive" (resend) them back into the main queue.

4. Interview Mastery

Q: "What is Idempotency and why is it mandatory for messaging?"

Architect Answer: "In a distributed system, a message might occasionally be delivered **Twice** (e.g., if the consumer crashes right after processing but before sending the 'Success' signal). An **Idempotent** operation is one that can be run 100 times with the same effect as running it once. If you are processing a payment, your code must check `HasThisOrderBeenPaidAlready?` before charging the credit card. Messaging is never 'Exactly Once'—it's always 'At Least Once,' so you must code for it."