Skip to main contentIBM Garage Event-Driven Reference Architecture

Advantages of Event-Driven Reference Architectures - Microservice

As we have seen in the introduction, modern business application needs to responds to events in real time, as the event happen, so it can deliver better user experiences and apply business rule on those events. The key is to be able to act quickly on those facts. Acting may involve computing analytics or machine trained models.

On top of that a modern cloud native application needs to be reactive, responsive and be able to be intelligence with rule engine and AI capabilities.

When adopting microservice implementation approach, the bounded context is defined with events and aggregates or main business entity. So each microservice is responsible to manage the operations of creating, updating and reading the data from a main business entity.

A web application, single page app (SPA), accesses the different microservices using RESTful API, to get the different data views it needs, or to post new data elements. The following diagram illustrates a simple view of the microservice challegenges:


When the user interface exposes form to enter data for one of the business entity, it calls a REST end point with a HTTP POST operation, then data are saved to data store: document oriented database or more SQL based RDBMS.

When a microservice (1) needs to access data from another service, then it calls another end point via an HTTP GET. A coupling exist, at the data schema level. A change to the data model, from the source microservice, impacts the service contract and so the callers. This may be acceptable when there is few microservices.

When the microservice dependencies grows in size and complexity, as illustrates by the following figure from Jack Kleeman’s Monzo study, we can see the coupling impact and the management and the cost to maintain such complexity.


Finally imagine we need to join data coming from two different services to address an urgent business request? Who will implement the join, service A or B? May be the simplest is to add a service C and implement the join: it will call two API end point, and try to reconcile data using primary keys on both business entities.


With event-driven microservices, the communication point becomes the Pub/Sub layer of the event backbone. By adopting an event-based approach for intercommunication between microservices, the microservices applications are naturally responsive (event-driven). This approach enhances the loose coupling nature of microservices because it decouples producers and consumers. The figure below illustrates, that microservices A and B produces facts about their business entities, and their life cycle to topic in the pub/sub event backbone:


The microservice C consumes those facts to build it own projection or view for supporting the join query.

When adopting technology like Kafka as event backbone then the data sharing is done via an event log, which can be kept for a very time period, and is replayble to improve resilience. These event style characteristics are increasingly important considerations when you develop microservices style applications. In practical terms microservices applications are a combination of synchronous API-driven, and asynchronous event-driven communication styles.