Microservices can communicate synchronously and asynchronously. These are the main group of communication means for microservices. Lest dig in to unwrap, what does it mean.

Synchronous communication means is sending a request to another microservice and waiting for a response. Opening a connection and waiting for a response. This is the most simple communication option for microservices. It is easy to implement and use, but it has its tradeoffs. The tradeoff is that your microservice is blocked by another microservice response. This type of communication creates temporal coupling. The implementation of synchronous communication can be either HTTP REST call calls or RPC.

When to use?

• Used when the user or client of the microservice expects an 'immediate' response. For example calculate book price based on all gathered parameters.
• You are implementing distributed transaction and want your application state to be as consistent as possible.

Pros and cons

✔️ simple to implement.

✔️ simple to understand (observe) the system.

❌ creates temporal coupling in the application.

❌ can cause performance issues in case target microservice is slow or overloaded.

❌ opens a lot of connections for big traffic. In case microservice throughput is limited, then it can cause a major performance issues.

Asynchronous communication is a communication style, when you are not getting the response right away. In some cases you are not getting a response at all. Three groups of communication patterns can be utilized for asynchronous programming.

• Request-Response communication - can be implemented as sync and also async with the queue based message brokers. Two queues are present, for requests and for responses. The sender will get the response from the queue marked with the correlation id.
• Event-driven communication - is communication pattern where sender does not wait for the response at all. It emits the event via the message broker. Other microservices can consume the event, if they are subscribed to it. This pattern ✔️ decouples microservices and letting them communicate via strictly defined interfaces. This pattern implies the ❌ complexity in understanding the application as a whole. The observability tools and practices can help this problem.
• Common data communication - is a pattern when all microservices are writing to the same data store. It can be filesystem or database. Then other microservices can read from this data storage. This pattern creates a ❌ common coupling (writing to the same data store) between microservices, but it is ✔️ simple to implement and maintain.

Pros and Cons

✔️ decouples microservices, letting them evolve independently

❌ increases complexity in the application

When to use?

• Use it when you need to decouple microservices. This communication style allows to do it completely.
• Use it for a long lived tasks. These tasks cannot provide immediate response. For example you need to check the number of books in the warehouse, before sending and marking in the system that it is sent. This type of task cannot be done synchronously.

Microservices, 2nd edition by Sam Newman

Fundamentals of Software Architecture: An Engineering Approach 1st Edition by Mark Richards (Author), Neal Ford

Note: The content in this article is a summary/interpretation inspired by them. Proper attribution is given to the respective authors.