Choosing the right communication style can save you 50% of them.
You can classify the communication into major groups.
Synchronous & Blocking:
- REST over HTTP
- GRPC
With request-response (synchronous), we expect the response to return to the instance that sent the request.
Asynchronous & Nonblocking:
- Queue-Based brokers
- Even-Driven
- Common Data
With asynchronous communication, the response can come back later, even to a different instance.
One of my favorites is Even-Driven
Event-driven communication is, by definition, asynchronous.
A microservice emits an event, and other microservices can react if they are interested.
An event is a statement that something happened (for example, OrderPlaced).
With event-driven communication, a microservice doesn't tell another microservice what to do.
It's up to downstream microservices to make a judgment call on what they do with that information.
Two things to consider:
- Event-driven collaboration can promote more loosely coupled architectures. But, understanding how the system behaves requires more work.
- You also need a message broker, which can further complicate matters.
Request-response and event-driven both have their place.
Some problems just fit one model more than another, and it's common for a microservice architecture to have a mix of styles.