When we are configuring a RabbitMQ instance one thing that we cannot forget to consider is that, in practice, the consumers of the queues may not be able to process some notifications or even the queue itself may reject messages due to some events. In that case, we must implement Dead Letter Exchanges, so it is possible to keep those messages and reprocess them some other time.

In this article, I intend to explain when to use Dead Letter Exchanges (DLXs), how to configure it at RabbitMQ and how a .NET Core application can be built to test the flow.

When to use Dead Letter Exchanges (DLXs)

Recently, I have had to specify the configuration of a RabbitMQ server and integrate a .NET application with it. To do so, I had some concerns, such as:

  1. Constantly, I come across applications that are hard to get up and running because of their dependencies. Sometimes the ReadMe file is well written, but there are so many things you have to do to run the application that you get tired. Therefore, for this integration with RabbitMQ, I would like that the development was easy to configure and with the fewest possible commands.
  2. Sometimes it is hard to maintain the development…

Elnatan Torres

Backend developer, passionate by .NET, father of a turtle and a chinchilla and step father of three dogs.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store