Samet Kaya

Samet Kaya

While many companies still struggle with the meaning and essence of a microservices architecture, there are increasingly more and more examples of successful implementations. Starting from scratch or migrating from a monolithic architecture, both have their own challenges and can be very time-consuming. Before starting your own journey, be ensured to evaluate if a microservices architecture is the right path for your company. If so, take your time to review some best practices and more here.

Two ways of communication

Microservices are all about separation of concerns and decoupling independent services. But how does communication between those services work? In a microservices architecture roughly two ways of communication between the microservices are distinguished:

    • Synchronous – a microservice directly calls the other microservice and requires an immediate response, which results in dependency between the services.
    • Asynchronous – a microservice directly/indirectly calls the other microservice and receive a non-immediate response in a new transaction. Requests between the corresponding services are placed in message queues. The responsible microservice takes all requests, processes it and returns the result to the caller in an asynchronous way. Local message queues can be used for this purpose, but often messaging frameworks like Apache Kafka, Apache ActiveMQ, RabbitMQ or any other scalable messaging solution provide the best capabilities to achieve guaranteed delivery.

Make the right choice

Both ways of communication have their own advantages and disadvantages but choosing the right one depends completely on your usecase and business / technical requirements. But why is this relevant? Because your choice has many implications and every time you think of a new microservice the question whether to choose for synchronous or asynchronous communication pops up. Without realizing we’re making the choice for the appropriate communication style constantly during our daily work. For example, if you want to contact a colleague or team member to ask a question, which communication method do you prefer? Do you need immediate assistance and prefer a phone call, which is obviously synchronous because someone directly needs to respond on your phone call? Or do you prefer an asynchronous method like email or your favorite collaboration tool in the office, because you don’t need immediate response and waiting for an answer is possible? Just like in normal life, the same applies to system to system communication. If your request is urgent and you need a direct response, synchronous communication is needed. In almost all other cases asynchronous communication is more suitable, because there is no urgency and no need for a direct response.

In a microservices architecture systems/applications/services constantly exchange information with each other. Designing a new microservice inevitability leads to the question which communication style should be chosen. Nowadays there is much focus on synchronous communication as the only way to go in a microservices architecture. It almost looks like microservices and synchronous communication styles like REST/HTTP/RPC are synonyms, but truly there is more than that. Asynchronous communication is still mainly the way to go if data/information is not immediately needed in a microservices landscape and in many cases this best practice applies. See this blog for further explanation and nice examples.


Source: Communication in a microservice architecture

Enterprise integration patterns

Combining synchronous and asynchronous communication within a microservices architecture leads to better results than using strictly one type of communication. Therefore I would like to guide you to the world of enterprise integration patterns. This excellent resource gives an overview of many best practices and more than 65 integration patterns, collected from integration practices in real projects. Some of the patterns are useful in many cases, but also explicitly fit in microservices architectures so I highlighted them in the table below:


Pattern Direction Asynchronous Multi-Message Termination Error Handling
Fire-and-Forget unidirectional provider single implicit none
Asynchronous Request-Response bidirectional provider two implicit none
Request-Response with Retry bidirectional provider multiple implicit retry
Polling bidirectional provider multiple implicit none
Subscribe-Notify bidirectional consumer and provider multiple explicit none
Quick acknowledgement bidirectional provider three implicit none

These proven patterns enable guaranteeing messages delivery, which is necessary in a landscape with independent services.

Asynchronous event-based architectures could help you in your journey moving from a traditional monolithic approach to a microservices or service-oriented architecture. Although there is no silver bullet, reading about the journeys of other companies could help you finding the right direction most suitable for your company size.

Next time I will elaborate more on this and related subjects. Please let me know your opinion or experiences via a comment or via LinkedIn. Thank you for reading.

If you want to stay informed of the latest news, please follow the eMagiz LinkedIn-page.