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 OK404 Not Found500 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.
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.
Run and submit the CLI tests.
The Boot.dev CLI requires you to be signed in to submit your solution!
Copy/paste one of the following commands into your terminal:
Run
bootdev run 1a81f164-aa4f-4f66-a481-fac6a99e1eba
Submit
bootdev run 1a81f164-aa4f-4f66-a481-fac6a99e1eba -s
To run and submit the tests for this lesson, you must have an active Boot.dev membership
Using the Bootdev CLI
The Bootdev CLI is the only way to submit your solution for this type of lesson. We need to be able to run commands in your environment to verify your solution.
You can install it here. It's a Go program hosted on GitHub, so you'll need Go installed as well. Instructions are on the GitHub page.