Before we start, let’s check a brief definition about what’s messaging:
“... It’s a development practice where we use messages to establish communication and integration in synchronous or asynchronous ways between applications, using a Message Broker or a MOM for this purpose…”
Message Broker or MOM (Message Oriented Middleware) are nothing more than a server (infra) built specific to process and support the send/receiving, redirecting and also monitoring the messages shared and exchanged between the systems integrated by message.
Initially, I’ll talk about the 5 main protocols most used today in projects:
We can list here the most used brokers in the IT industry today and which protocol they support. There are more than the ones mentioned here, but I focused on the main ones that I saw during some projects.
At this point of the article, I’ll share 3 main patterns of integration when using messaging and a message broker.
The exchange of the information is based on queues, where the message is sent initially by an application that we call producer and the message is consumed by another application (or others applications) that we can call as consumers. Those consumers are “listening” to a specific queue.
In this model, it’s possible for one message to be consumed (one-to-one). So, even if several consumers listen to the same queue, only one consumer will get the message only one time and the message itself will no longer be at the broker.
Also known as the model “Pub/Sub”, it’s based on topics, where the messages are sent by the producer and delivered to all consumers applications that can “assign” on this topic.
This model allows that the message can be delivered to several consumers (one-to-many), so, consumers that use the durable sign to the topic, can consume the messages while they are active on the broker.
The name “Dead Letter” comes from a pattern of the Mail, where a specific letter can’t be delivered, so it’s sent to a “department” or someone “responsible” to take some action about this letter that was not delivered for any reason.
We have something similar when dealing with messaging. When it’s not possible to deliver a message, there’s an option to have a “queue” where we can send this message for someone to take an action, as it was not consumed by nobody.
Here we need an important comment. The DLQ (as this dead letter is commonly named) is responsible for receiving messages that were not delivered or not consumed. Using the DLQ as an error message for integration errors or fails is wrong. When the integration fails, we can use another type of queue or even create alerts/notifications in the monitoring tools to take action from someone, depending on the Broker you are using on your project.
The subject messaging also is actually linked, when we’re working on a project related to Microservices Architecture.
Once every microservice should be independent from each other, but even that, we have the need to share data, send data to other microservice or some notifications related to an event that happened.
Using messaging, we can solve many of these communication scenarios between microservices without increasing the coupling between them, and keeping them independent from each other.
Let’s talk about a pattern called Event Sourcing. This one is most used for Event Driven Architectures.
This is an architectural pattern when implementing Microservices. Event sourcing uses messaging, to propagate data by events triggered by a first microservice, with the purpose of sharing this information with others, and keep the consistency of data for the microservices that share the same data. This pattern is also linked to the CQRS pattern, helping for the low coupling for our architecture.
We can see in the image below an example of information that needs to be shared between microservices and keeping the updated data for both.
In this final segment of the article, shall I mention some of the principal advantages and disadvantages when using messaging in software development projects.
Want to know more? Click on the link and book an appointment with our experts: