Over my 4 years working as a Software Developer I have made hundreds of code reviews and this recurring practice in my day-to-day motivated me to create some kind of checklist of what I must evaluate on each pull request in order to say if some code is good or not to go to production environment.
This article does not intend to be a “bible” of how to make a code review, since I know that there is a lot of other practices made by other developers that are as important as the ones I’m going to list, but it…
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.
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:
Backend developer, passionate by .NET, father of a turtle and a chinchilla and step father of three dogs.