Synchronous and Asynchronous Communication between Microservices



1646 views Designing μ-services



Say, we are building a Social Network and anytime someone reacts to your post, you need to be notified. So, how should the Reaction service talk to the Notification service to send out a notification?

The communication would be much simpler and reliable, just a function call if it was a monolith; but things become tricky as we go distributed.

Microservices need to talk to each other to exchange information and get things done; and there are two categories of communication patterns - Synchronous and Asynchronous.

Synchronous Communication

Communication is synchronous when one service sends a request to another service and waits for the response before proceeding further.

The most common implementation of Sync communication is over HTTP using protocols like REST, GraphQL, and gRPC.

Advantages of Synchronous Communication

  • It is simple and intuitive
  • Communication happens in realtime

Disadvantages of Synchronous Communication

  • Caller is blocked until the response is received
  • Servers need to be pro-actively provisioned for peaks
  • There is a risk of cascading failures
  • The participating services are strongly coupled

When to use Synchronous Communication

  • When you cannot proceed without a response from the other service
  • When you want real-time responses
  • When it takes less time to compute and respond

Asynchronous Communication

The communication is asynchronous when the one service sends a request to another service and does NOT wait for the response; instead, it continues with its own execution.

Async communication is most commonly implemented using a message broker like RabbitMQ, SQS, Kafka, Kinesis, etc.

Advantages of Asynchronous Communication

  • Services do not need to wait for the response and can move on
  • Services can handle surges and spikes better
  • Servers do not need to be proactively provisioned
  • No extra network hop due to Load Balancer
  • No request drop due to target service being overwhelmed
  • Better control over failures and retires is possible
  • Services are truly decoupled

Disadvantages of Asynchronous Communication

  • Eventual consistency
  • Broker could become a SPoF
  • It is harder to track the flow of the message between services

When to use Asynchronous Communication

  • When delay in processing is okay
  • When the job at hand is long-running and takes time to execute
  • When multiple services need to react to the same event
  • When it is okay for the processing to fail and you are allowed to retry

Arpit Bhayani

Arpit's Newsletter

CS newsletter for the curious engineers

❤️ by 14000+ readers

If you like what you read subscribe you can always subscribe to my newsletter and get the post delivered straight to your inbox. I write essays on various engineering topics and share it through my weekly newsletter.




Other videos that you might like


Introduction to RPC - Remote Procedure Calls

1531 views 97 likes 2022-05-13

One of the most interesting things that revived itself after a decade is Remote Procedure Calls, fondly called as RPCs; ...

Designing Workflows in Microservices - Orchestration vs Choreography

1659 views 111 likes 2022-05-11

In a microservices architecture there will always arise a need to design workflows; for example: when on an e-commerce w...

Synchronous and Asynchronous Communication between Microservices

1646 views 106 likes 2022-05-04

How should two microservices talk to each other? Picking the right communication pattern is super-important as a good de...

Should some microservices share a database?

1814 views 97 likes 2022-04-27

Microservices need to communicate with each other. Communication between them is always about getting or updating data t...


Arpit's Newsletter read by 14000+ engineers

🔥 Thrice a week, in your inbox, an essay about system design, distributed systems, microservices, programming languages internals, or a deep dive on some super-clever algorithm, or just a few tips on building highly scalable distributed systems.



  • v10.6.4
  • © Arpit Bhayani, 2022