Sync vs Async Interprocess communication in Microservices Acthictecture. When to use which?

I spend the first half of 2020 researching about how services should communication with each other in Microservices architecture. This was a topic that I was and still genuinely interested and curious about and turn it into my Master thesis research. 

I then turn my work into a scientific paper and got it published at the "International Workshop on Quantitative Approaches to Software Quality, 2020" which you can read it here for free.

But I wanted to write this blog post to explain what I did in a much more practical and less academic terms. So here we go:

What is Interprocess communication?

In simple term, IPC is the mechanism for two independent processes to communicate with each other in order to exchange information.

Take a look at above diagram that I found here as an example, IPC is about answering how the RED service, can communicate with the Green service. What protocol it uses? does it use REST API over HTTP or some other protocol.  

and what message format is going to be the default format? Will is be  non-binary format such JSON, or XML, or will it be binary format like Protocol Buffer etc... ?

Why does it matter?

Based on the extensive research I did, deciding on how microservices communicate with each other is one of the most important and fundamental decisions to make when implementing a system based on a microservices architecture that impacts system from several non-functional requirements such as Availability, Performance Latency, and Scalability.

IPC plays a much more critical role in microservices architecture as it does in Monolithic, that is because in monolithic architecture module can access and invoke each other at the language level, in contrast, microservices structure the system as a set of independent distributed service with the possibility that each service could run on a different host than the other.

How many type of IPC we have out there?

There are fashionably TWO type of IPC mode:

• Synchronous methods,
• Asynchronous methods

The most common type for synchronous method would be REST API, and gRPC. In Synchronous pattern the communication between service is direct, and both services must be up and running at all a time otherwise the request will fail.

In the other hand, there is no direct interaction between microservices in the Asynchronous pattern. instead all the interaction takes place via an intermediary often called Message Broker. Nowadays all the major public cloud providers provide their own SaaS version of these message broker such as AWS SNS, Azure Message Bus, and Gcloud Pub/Sub. There are also many open source message broker such as RabbitMQ, ActiveMQ and etc... In nutshell they all operate very similarly to each other.

Which one should I use?

In general, Asynchronous methods offers several advantages over it's Synchronous rivals related to availability and performance latency especially when the load in the system goes high. Having said that Asynchronous pattern is not a universal solution that can suit all situations.

To elaborate more, if the scenario that you are building requires an immediate answer from the server (either success or failure) then Synchronous pattern is more suitable to be utilized, but if your scenario does not require immediate process and response then by all means you should go with Asynchronous approach.

Let me clarify above statement with an example: Imagine you are designing a microservices-based system for an e-commerce scenario. Now think of a product page. The customer sends a request to the system by providing the ProductID and expects the page to be displayed immediately OR an error gets displayed to the user.  Behind the scene there might be several microservices involved for that page to be displayed, for instance:

1) Service A: Responsible for fetching key metadata for that product ID. example: product name, colour, size, price.

2) Service B: Responsible for fetching all the reviews for that product.

3) Service C: Responsible for fetching product recommendation for that product, A.KA, Customer who bought this also bought...

4) Service D: Responsible for fetching available shipping options for that product.

In the above example, it's more appropriate for the communication to take place using Synchronous communication since this scenario requires an immediate response for the system.

Now, within the same e-commerce scenario imaging, customer checkout component. When the customer place it's order there might be several microservices involved. For example: 

1) Customer Notification Service: Responsible for sending email to customer,

2) Seller notification Service: Responsible for sending email to the product seller. (if any)

3) Payment processor service: Responsible for debiting the customer credit card the respective amount.

4) Inventory service: To update the inventory quantity.

In this particular scenario, the customer does not need to wait for all the services to be processes, instead, we can show a page (often in Green color) that says your order has been received. Each microservice will then take that order id and process it accordingly, in such scenario Asynchronous pattern can offer numerous advantages over it's synchronous rivals.