Inter service communication: message bus

Last week we covered request/response communication and now it is time to talk about the complete opposite; message bus communication.

The message bus communication strategy makes the producers and consumers of data completely decoupled from each other. Except that they obviously need to understand the data on the message bus. The producer does not know who (if anybody) consumes what data more does the consumer know who is producing the data received.

A huge benefit is the decoupling as new consumers can be added very easily without changing the producers. However on the downside is the fact that the producers need to put data on the message bus even when nobody is looking for that data sometimes leading to a message bus infrastructure requiring more resources than necessary. So blindly publishing data in case somebody needs it might not be such a great idea.

Data on the message bus also tends to be fire and forget meaning that once a message is on the bus there is no way to know what that message resulted in. This means that a client that wants to know if a certain message was processed by a specific server needs to implement its own request/response protocol on top of the message bus. But then we are not talking about message bus communication but rather request/response communication that we already covered.

Next week we will cover a compromise; pub/sub communication.