Nowadays, building systems using microservices is almost a must, but applying and keeping microservices concepts is quite challenging. We want service providers to process all requests, even in cases of high demand, but how can we guarantee this, and how can we improve performance? The answer is message queues. So what's a message queue, and how does it work?

What is a Message Queue?

A message queue is an architecture that provides asynchronous communication, allowing microservices to interact with each other without coupling. The communication is made by sending messages that contain information or commands that need to be processed. The sender is called the Producer. These messages are then stored (in memory or persisted) in a queue and processed by another microservice (called the Consumer). Then, once a message is processed, it is removed or dequeued, which assures that it is processed only once.

Types of Message Queues

Okay, this seems great, but what if we need the same message to be processed by two or more microservices? Well, there are different types of message queues:

1. A message queue can be point-to-point, where there is only one queue  and one consumer:

Image courtesy of Oracle 

2. Alternatively, a message queue can use a Publisher-Subscriber format, where a Publisher (Producer) sends a message to a queue (in this case called a Topic), and all the Subscribers receive a copy of the message that can be retained or not:

Image courtesy of Oracle

Benefits of Message Queues

• Redundancy: After storing the message, the queue assures the message will only be removed once the process that reads it confirms its success in reading and processing. If anything goes wrong, the message won't be lost and reprocessed later.
•  
• Asynchronous Messaging: In cases where your application doesn't require a response right way for a process, the service that consumes these messages can run its business logic at its own pace.
•  
• Resiliency: Let's say, for example, that your system consists of two microservices, one for processing orders and another for sending emails. Having a queue to indicate that an email needs to be sent means that even if your email system is down, the order-processing microservice can keep receiving and processing orders. When the email service is back online, it can start reading the messages and sending the emails.
  
  
• Scalability: Queues allow you to decouple your system into different microservices and scale them by demand.

Conclusion

To conclude, if you are thinking of creating microservices or if you need to improve their performance and the business logic doesn't require that they be processed immediately, then message queues are what you need. They will guarantee that all received requests are processed while decoupled from other microservices, and, if needed, they allow you to easily scale for periods of high demand.