In a Micro Services architecture, you need to decide how microservices will communicate between each-other.

When I say "communicate", I mean a Microservice A sending a command to a Microservice B, and then Microservice B sending the response to Microservice A.

This can be done synchronously (with REST API calls) or asynchronously (using a messages bus).

Where the first possibility is quite obvious, the second one needs some clarifications.

This second possibility is called the "Asynchronous request/reply" Architecture pattern.

Here is drawing describing this pattern:

Drawing explanations:

1. A Microservice A (on the left) publishes a command message on the messages bus. This command message's header contains :

   • a correlation id
   • a reply topic
   • a reply partition

2. A Microservice B (on the right) consumes the command message and publish in return the response message on the topic and partition specified into the command message's header.

3. The Microservice B adds the correlation id into the response message's header, so the Microservice A is able to match the response for the request.

4. Microservice A consumes messages from the message broker topic and partition specified into the message command (see step 1).

5. When Microservice A consumes the message having the right correlation id, it gets its response.

The drawing also shows how a scaled Microservice A can handle different "request/reply" when running on several pods. This issue is addressed using different partitions on the message broker, each pod being bound to a specific partition.

---

Benefits:

• non-blocking call
• client/service decoupling: commands are sent on a topic instead of a service's endpoint
• messages buffering: commands and responses are consume at each service pace - they on the bus waiting to be consumed
• fault-tolerance: as commands and responses remain on the bus until they are consumed, the service can be down. commands and responses will be consumed as soon as the service is back

Drawbacks:

• topics multiplication: you need 2 topic per resource (topic for request and topic for reply)
• code complexity: the code become much more complex than a synchronous endpoint request

Note:

This pattern is suitable for applications with huge concurrent requests.