Blog

Microservices architecture principle #4: Asynchronous communication over synchronous communication

29 May, 2015
Xebia Background Header Wave

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.“]

Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts