As far as I know, there are two commonly used patterns when dealing with services communication in a microservices architecture:
- Direct-calling other services. For example: Service
Ahandles some data, then it needs to tell Service
Bto do something with that data.
B's endpoint URL and calls it directly.
- Using a bus (commonly a Message Queue) to dispatch messages which will be picked up by the single microservices. For example:
Awill send a message on a common queue,
Bwill receive it and will know what to do.
Both have downsides:
- Direct-calling other services leads to tight coupling services to other services. If you change service
B, you'll likely need to adapt and re-deploy also all other services that interact with
- Using a bus is cool because you don't need to know which service will be able to handle the request, but if the MQ fails for whatever reason it will become the single point of failure of the entire system.
So, what is the preferred way of managing service communications?
Do we have alternatives which can reduce failures and avoid tight-coupling between microservices?