Dead Letter

In a point-to-point system, the sender and receiver are tightly coupled. The sender immediately knows if the message was successfully delivered to the receiver. For example, with HTTP requests, we get simple response codes like:

200 OK
404 Not Found
500 Internal Server Error

In an asynchronous system like RabbitMQ, the sender and receiver are decoupled. The sender doesn't need to know if the message was successfully delivered to the receiver. That has benefits, like simplicity and performance, but it also means that the chance of bugs increases.

Dead Letter Exchanges and Queues

To address this, it's common in PubSub systems to aggregate messages that fail to be processed into a dead letter queue. Queues can be configured to send messages that fail to be processed to a dead letter exchange, which then routes the message to a dead letter queue.

Assignment

We're going to send all failed messages in the Peril system to a single dead letter exchange/queue. It will act as a log. This queue won't have any consumers, we'll just let the messages pile up so we can inspect them manually using the RabbitMQ management UI.

Using the UI, create a new exchange called peril_dlx of type fanout. Use the default settings.

Fanout is a good choice because we want all failed messages sent to the exchange to be routed to the queue, without needing to worry about routing keys.

Using the UI, create a new queue called peril_dlq.
Go to the queue's page and bind the queue to the peril_dlx exchange with no routing key. Leave the default settings.

Run and submit the CLI tests.