Messaging Pattern For High Availability and Handling Failures in Microservices 🔥

We at Propelld ( A Fintech Startup ) are using microservices architecture for our business requirements. It was because we needed to be quicker in our deployment cycles (You may already know Business People 😜). It is helpful for developers from a different background for easily contributing to architecture providing flexibility in choosing the language for the feature they build.

But microservices do come with challenges like Failures, Fault Tolerance, monitoring, and logging etc.

Microservices Trend

How it all started?

I was given the task to implement Email Service that requires email to be sent at various steps in the process. The challenges with Email Service was to maintain High Availability and Prevent Fails. My mentor threw some concepts like message-driven and event-driven approaches in order to implement that. I settled on message-driven approach as it seemed to best fit in our scenario.

Challenges that were being faced?

• 3rd Party API's provided by SMTP Servers could fail.
• Internal Services had the chances of failures.
• High Availability of Email Service.

Messaging Pattern coming into the picture.

Lets first understand messaging pattern.

Message pattern is a design pattern which enables services to communicate each other by sending messages. Messaging Pattern involves messaging queues, publisher or producer and consumers. Messaging Queue is a temporary persistence for messages that were not sent due to some failure on end service. Producers publishes messages into message queue and whenever new message comes to queue, consumer consumes the message from message queue in order to process further.

Message Queuing

The above diagram illustrates the basic message queuing and components involved.

Publisher Or Producer is responsible for publishing a message to the message queue. For trackability or status of the task, we can persist the task and initial status before publishing to the queue.

Messaging Queue act as temporary storage where the published message is stored for the time being consumer hasn't acted on it or it has not been fully processed. For example. if the task to be performed wasn't successful we could re-queue the message and act on it later. RabbitMq, Kafka, and ActiveMq etc. are some of the message brokers which act as messaging queues and provides additional superpowers to the messaging pattern.

The Consumer is what responsible to process the message and it knows how to act for that message. For example. it will further make calls to other APIs with the context of this message for doing the required task.

My Use Case for Email Service

Lets Breakdown in simple parts

Taking a simple example like sending Forgot Password Email, the authentication service or user service (we are leveraging microservice concept) will send the request to email service and that would further to the messaging service which will ensure the email is sent in nth retries and p unit of time after.

Flow Of Sending Email

Solving Challenges that were being faced?

• 3rd Party API’s provided by SMTP Server could fail:

Even if for some time due to some threshold set or API down the messaging pattern would enable to retry and send the email.

• Internal Services had the chances of failures.

If our Email service is down when Auth service is registering the request we could easily notify for trying after some time. And in order to prevent this, we could use Horizontal Scaling.

• High Availability of Email Service.

Horizontal Scaling and the ability to send email even if the 3rd Party services are down we ensure high availability of our Email Service.

Note: Maintaining Status like pending, sent-to-queue, retrying etc could be helpful in understanding the failures and debugging the issues.

The Bigger Question

When and why should you use Messaging Pattern?

Messaging Pattern for microservices helps to solve challenges of failures, high availability, and post-processing. Distributed architecture can leverage the messaging pattern for scaling the application according to the business needs. The use case suggested above like Emails, SMS or PDF generation can efficiently be designed with the messaging pattern.

Above all, the scenario varies from business needs and the resources allocated to cater to that needs.

Do implement Monitoring And Logging for your services for better debugging of microservices and messaging flow.

Hope you liked the content and if I did miss something or you want to let me know some cool patterns, please let me know.

Thanks and Cheers🎉