EN 
NL While many companies still struggle with the meaning and essence of a microservice architecture, the examples of successful implementations are increasing. 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 microservice architecture is the right path for your company. If so, take your time to review some best practices and more here.
Microservices: 2 ways of communication
Microservices are all about separation of concerns and decoupling independent services. But how does communication between those services work? In a microservice 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.
Create your microservice architecture: pick your form of communication
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 microservice architecture systems/applications/services constantly exchange information with each other. Designing a new microservice or microservice architecture 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 microservice architecture. It almost looks like microservices and synchronous communication styles like REST/HTTP/RPC are synonyms, but actually there is more than that. Asynchronous communication is still mainly the way to go if data/information is not immediately needed in a microservice architecture and in many cases this best practice applies.
Source: Communication in a microservice architecture
Enterprise integration patterns
Combining synchronous and asynchronous communication within a microservice 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 a microservice architecture, 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 microservice architecture with independent services. Asynchronous event-based architectures could help you in your journey moving from a traditional monolithic approach to a service-oriented or microservice 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.
Bedankt voor het lezen van deze blog over loosely coupled applicaties in een microservice-architectuur.
By Samet Kaya, Software Delivery Manager @ eMagiz
