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 ServiceBto do something with that data.AknowsB'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 withB. - 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?
Best Answer
As you rightly say, having a component dedicated to pass around messages is definitely better than having every service responsible for knowing how exactly to reach all collaborating services. Therefore, message queues, communication buses etc. are a good idea.
And if they become a single point of failure? Well, you do what you always do for robustness and scaling: you deploy multiple instances of the message queue. If your environment can't keep any of them up, chances are you're not going to get any useful work done anyway. Problem solved.