Microservices is an architectural style that structures an application as a collection of services that are loosely coupled, highly maintainable, pluggable, and owned by small teams based on services.

Microservice architecture helps you in scaling your complex application, deploy services independently, rapid delivery of new features, and fully testable. Around microservice-based architecture, we are also able to utilize diverse tech stacks. So before starting out with your next Microservice application, you need to keep one important term in mind, i.e. Messaging Queue.
A message queue is a form of asynchronous inter-service communication. Messages are stored on the queue until they are processed and deleted. Each message is processed only once, by a single consumer. Message queues can be used to decouple heavyweight processing, to buffer or batch work, and to smooth spiky workloads. Common messaging tools are Kafka, RabbitMQ, AWS SQS.
Let dive into Messaging queue and learn why do we need them in a Microservice architecture.

Message Queue

A message queue is a queue of messages sent between services/applications. A message is some information that is produced by a producer application in byte form, stored in a queue and is consumed by a consumer application.
The best thing about a message queue is even when some service is offline, the message queue preserves the message in the queue and can be retrieved by the consumer.

Let’s say we have a Digital Signing service SignMe. With SignMe we enable organizations to send documents to people for electronic signatures. Once someone creates a document and has to send it for signature, they need to add recipients. Now to inform recipients, we need to send them an email. We also need to send recipients a reminder to sign the documents if they forget to sign after x days. Let’s think of some approach where we can send emails to the recipients.

There is one service where a sender goes and creates a template, adds recipients, and sends the envelope for signature. There is another notification service that sends the recipient notifications as email or push notifications. We want to send emails to end recipients with the help of messaging queue.

We can either have a rest synchronous architecture, where we have an external call to notification service and wait for the response, or an asynchronous messaging queue.
Synchronous call to notification service will block the current thread until the request is resolved and for any failure in the service, it will give an exception and we will lose the current process. If the goal is to support a few hundreds or thousands of users, then a simple rest synchronous architecture will be a good choice to go with.
However, when we talk of large-scale applications where tens of thousands of requests are created, we need to use the Messaging queue.

To send emails, how can we do it?

Our Envelope Sending service will be a publisher which pushes these notification actions to some topic of messaging queue and, respond back to the users. So once we write the message to the queue, the notification service which acts as a consumer can read messages from the queue and, process them asynchronously.
So this is how we can achieve high reliability, scalability, and true decoupling. In certain scenarios when our dependency services are down, we still have the messages stored safely with us in the queue which we can retrieve later. Wonderful, right? Let me know your thoughts in the comments.