Async Communication and Microservices: a perfect marriage?

Synchronous communication means that both parties communicate directly with each other. The exchange of information happens through the established communication channel.

The communication typically starts when a client (the party needing the information) sends out a request to the provider (the party that has the information). The provider receives the request, processes it immediately and sends back his answer.

One could say that by sending a request to the provider, the client opens a communication channel and the response is sent back through the same channel.

1. Client sends the request (channel is opened)
2. Provider processes the request
3. Provider sends back its answer (using the channel)
4. Client receives the answer

There are different patterns to implement this protocol. Beside the traditional Request-Response pattern we see also new patterns emerging like streaming.

The request-response pattern is best known by everyone as it is implemented by many technologies such as REST APIs, SOAP services and the newer gRPC.

The streaming pattern is somewhat special however, as here the data is pushed to the client. In order for the client not to “lose” any data it must always be available when the provider wants to send data to it. Moreover, the Provider must be stateful because it needs to know to which clients it needs to send the data.

But all these synchronous communications have the same major drawbacks:

Mainly because of the second drawback only use this style if the answer is really needed in real-time (be very critical if this is really the case). Or if you need the supporting functionality such as monetization, monitoring, rate limiting … which is better implemented (through the use of API Gateways) in this communication style.

In all other cases try to avoid it!

Asynchronous Communication is a communication style where the different components communicate by exchanging messages. In general, the communication between the different actors is facilitated by an intermediate component called Message Broker (not needed: see webhooks). As the communication is defined as “asynchronous” the client will never wait (block) for a response. As such provider and client can operate independently from each other. A failure in one has no direct impact on the other.

Asynchronous Communication normally consists of the following building blocks:

There are different implementation patterns to achieve this communication style (Eventing, Command messages, webhooks). Detailing those is beyond the scope of this blog but we will briefly touch on the concept of eventing as this is regularly discussed in microservice architecture.

It is important to make a distinction within your architecture between these events. They may look the same at first, but their purpose is different, and they will deviate over time. Separating them will allow to manage these different lifecycles better in the future.

Depending on your needs the structure of your events can also differ (State Carrying Events vs Notification Events). But again, we will not dive into the details of that topic in this blog.

Regardless of which implementation pattern you choose, asynchronous communication has the following advantages:

There are however also drawbacks:

Regardless of these drawbacks, we strongly believe that the advantages considerably outweigh these shortcomings as most of them have very simple mitigations solutions.