Microservices architecture principle #4: Asynchronous communication over synchronous communication

29 May, 2015

This post is part of a six-part series on Microservices Principles. Other parts are: Business Capability,  Autonomy, Small bounded context, Best Technology and One Team.
Microservices are a hot topic. Because of that a lot of people are saying a lot of things. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture.
This blog explains why we prefer asynchronous communication over synchronous communication
In a previous post in this series we explained that we prefer autonomy of Microservices over coordination between Microservices. That does not imply a Microservices landscape with all Microservices running without being dependent on any other Microservice. There will always be dependencies, but we try to minimise the number of dependencies.  Once you have minimised the number of dependencies, how should these be implemented such that autonomy is maintained as much as possible? Synchronous dependencies between services imply that the calling service is blocked and waiting for a response by the called service before continuing it’s operation. This is tight coupling, does not scale very well, and the calling service may be impacted by errors in the called service. In a high available robust Microservices landscape that is not preferable. Measures can be taken (think of things like circuit breakers) but it requires extra effort.
The preferred alternative is to use asynchronous communication. In this pattern the calling service simply publishes it’s request (or data) and continues with other work (unrelated to  this request). The service has a separate thread listening for incoming responses (or data) and processes these when they come in. It is not blocking and waiting for a response after it sent a request, this improves scalability. Problems in another service will not break this service. If other services are temporarily broken the calling service might not be able to complete a process completely, but the calling service is not broken itself. Thus using the asynchronous pattern the services are more decoupled compared to the synchronous pattern and which preserves the autonomy of the service .
[edited: 3 aug 2015 – added preamble and removed line “Over the next couple of days we will cover each of these principles in more detail in a series of blog posts.“]

Newest Most Voted
Inline Feedbacks
View all comments
Greg Young
7 years ago

aka Tell Don’t Ask. Tell me something happened (event) vs asking me for current state.
There are also some places where you much prefer the ask. Its a matter of optimizing for autonomy vs authority (sometimes you prefer authority)

Jesse Tomchak
Jesse Tomchak
7 years ago
Reply to  Greg Young

What is an example of where you’d prefer authority over autonomy?

Greg Young
7 years ago
Reply to  Jesse Tomchak

I can give lots of examples where you would prefer authority of autonomy.
Google maps is a good one. Do we really want to synchronize down all the maps on the planet to your mobile phone so you can query autonomously? Its quite common that you are interested in very small slices of a very large dataset in which case you suck it up and understand the possibility of problems.
Another example might be a police information system. A big requirement is that all views of data and searches are logged. Only the authority is trusted to do this (there are some ways of implementing this without having authority such as encryption and make the key provider an authority)
Another example would be when you would prefer to give no answer as opposed to having the possibility of conflicting answers.

4 years ago

Want to know any example where we prefer Async MicroService over Sync Microservice? Any real example would be appriciated.

Explore related posts