Microservices communication: Avoiding single point of failure

Question

As far as I know, there are two commonly used patterns when dealing with services communication in a microservices architecture:

1. Direct-calling other services. For example: Service A handles some data, then it needs to tell Service B to do something with that data. A knows B's endpoint URL and calls it directly.
2. Using a bus (commonly a Message Queue) to dispatch messages which will be picked up by the single microservices. For example: A will send a message on a common queue, B will 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 B.
• 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?

Answer 1

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.

Answer 2

Well, let's say service B fails and is not responsive. Now the whole process cannot continue since it still depends on B to do its part of the work. How is B not a single point of failure then?

The advantage I see with having a common bus (or orchestrator, or whatever you have) is the ability to handle single services downtime, e.g. the queue can still keep the messages sent to B until the service is back up and able to consume them.

Also the chances of keeping a single highly available system up are better than having to worry about N different systems with different owners.

Here's an interesting post by Martin Fowler that provides a solution to microservices using events that I think you could use.

Answer 3

Whether one topology or the other is best will largely depend on what form your communication takes.

For example, if you're mostly sending through self contained messages that don't require an extensive conversation between services then a brokered message bus works well. This is particularly true if the messages need to reach multiple services or you're agnostic to which service picks up the message. Resilience can be managed with a clustered broker setup that most of the popular message brokers can handle.

If you're communications are mostly two-way, however, peer-to-peer may be the way to go. This would be particularly true if you're streaming data between the services. There are various techniques for mitigating the coupling such as using a discovery service for identifying an appropriate partner. There are also common techniques for limiting interface coupling. For example, having a REST-like API and using an extensible, declarative interface for the business communication. JSON is a popular format, XML was before that etc.

Now that's not to say that you can't perform peer-to-peer through a message bus but you end up managing a lot of session state which can complicate things. If your comms is mostly event with a bit of peer-to-peer it may well still be preferable to do this to keep just one messaging system.

Similarly, if you are mostly streaming with a bit of message passing, you may well embed an event protocol into the streaming protocol for the same reason.

And these aren't your only options. For complex setups, I quite like using ZeroMQ whereby I use one communications "fabric" but apply appropriate topologies where necessary.

In summary, the best messaging topology depends on the nature of the messages. There isn't one correct answer but, on the positive side, it's a well trodden path. You should be able to get good, off-the-shelf, solutions with sensible mitigations unless you're doing something very unusual.