Communication between microsevices using a Business Event Based approach via an Event Broker Service
When integrating Microservices, the principle of “independence” means thatit is desirable to avoid directly coupling the services. A commonly used technique is to use a message queue to provide the integration required, as shown:
When Sevice A needs to integrate with another service, a new queue is used:
Now, let’s give these services some example names, say Service A is the Customer Service, and B and C are the Order and CRM services respectively. The message passed is the customer entity details. The oder service needs to know about the customer details, and the CRM srvice also needs to be updated with the same info. The picture now looks like:
Ok, this all looks fine, and is a sensible way of integrating the services without directly coupling them. Now let’s add in a few more services and entities that would contribute to an order, say Catalog Item and Address Services. This requires queues for each of these entities. To keep the diagram tidy let’s move the message entity name onto the queues. We now have the components of an order feeding into the Order Service and the customer details being passed to the CRM system:
Of course, it would probably be neccesary need to pass the order details to the CRM service so another queue between order and CRM is required, like so:
So far so good. Now, let’s say add a requrement to integrate the order service with another MI Reporting service. This needs another instance of an Order Details Queue:
We are starting to suffer from proliferation of duplicate queues. As we add more services to the mix the problem increases almost exponentially with every new service.
If we switch to a publish-subscibe pattern rather than point to point queues, we eliminate this duplication. To make effective use of a Pub-Sub model it is helpful to think in terms of “business events” and use an event broker pattern to mediate between services. So each service no longer talks directly to a queue, but talks instead to the broker publisher servie to publish an event, e.g. Order Updated. That changes our picture to look like this:
If we move the other service integrations into the broker so all communications are mediated by it then the picture looks like this:
So in the placing of an order the sequence diagram would be as shown:
