Properties and Benefits of an Enterprise Event Broker
Background
An Enterprise Event Broker acts as the communication hub for all business events and hence for communication between microservices. This is an evolution of the Mediated Services Model which was itself an evolution of the API Services model, as shown below:
The API Services model has the services all directly coupled. The calling service knows details of the APIs it is calling. This leads to fragility and a lack of robustness.
The mediated API services model reduces coupling, but still requires a level of coupling as the calling service need to know what API the mediator is calling, even though a level of abstraction can be introduced; there has to be a service implementing the API which is being mediated and the called API is known to the client, even if indirectly.
The Event Notification Model leads to the lowest level of coupling between the services as the APIs being notified are totally independent of the calling service and nothing is known about then by the calling service. The calling service does not even know if any APIs exist to be notified, or indeed, care.
Architectural Benefits of using an Event Broker for Microservice communication
The Broker allows a total decoupling of event publishers and subscribers.
The Broker does not contain any business logic, following the principle of “dumb pipes and smart endpoints”, all business logic is contained in the subcribers to the event.
The Broker can enable role based security on the subcriptions, so only authorised subscribers can receive events. This provides a standardised method of securing services.
The Broker can Audit all business events raised by event publishers. It can also audit all notifications raised to to event subscribers. This audit trail allows reconstruction of system state at any point, in a similar manner to the transaction log of a SQL database.
The Broker defines an Enterprise Architectural pattern for inter-service communication. This ensures consistency of communication.
Business Benefits of using an Event Broker for Microservice communication
The key distinction of Event Driven Architecture and the key responsibility of an event broker is the managed asynchronous autonomy of services (sources and handlers of event notifications). For example, an “order placed” event notification issued by a Order Service is posted to the broker instead of directly invoking the Packaging Service. In this approach, the User placing the order, the Packaging Service and the Customer Relations Team all can be notified without the Order Service connecting directly with any of them, and without the overall operation depending on the simultaneous availability of all the services.
The key business benefit is the potential access to continuous intelligence and real-time business awareness and responsiveness. Dispatching events to multiple endpoints, some for immediate analysis and decision making, others for storage and later processing, provides the business with both the real time and the later, consolidated analyses to deliver rich, continuous intelligence opportunities. An event broker serving as the dispatcher of the event stream data is the key enabler for this business benefit.
0 Comments