In this article, we will explore the event sourcing model pattern in event-based inter-service communication in the microservice architecture. This article is part of the previous, microservice inter-service communication.
Event Sourcing
Event sourcing is the process of modelling your system driven around events. And by events, we mean the current state and the changes occurred in that state in different stages. An object is maintained by storing a sequence of events that show the changes occurred in the state and every new change that has occurred is appended to that sequence. Almost everyone is modelled in event sourcing style. You can see that whenever a process is explained, it is not done so with the help of joins or tables, but as a series of events or like a story you might say.
All the events are maintained in an event store, which acts as a database for all the events. However, an event can also be subscribed to by any user with the help of some API. When subscribed, the event can then be provided to the subscriber through an event store. The event store is what keeps all the event-driven microservices architecture up and running.
In this pattern, we have to define event classes. In our example, these might be as follows OrderCreated, OrderCanceled, OrderApproved, OrderRejected, and OrderShipped. The following diagram shows how to create an order for a book:
As you can see in the preceding diagram, the Order Service creates an order for a book and inserts a row into the Order Table. It also publishes the event to the event store, where other services subscribe to events. For example, the Account Service subscribes to events regarding customer management and the Book Service subscribes to events regarding inventory management.
In an event-based architecture, you can update an order as follows:
As you can see in the preceding diagram, a customer generates an update order request. The event source receives this order and the application finds the order using find the event by order ID. It then updates the order and saves it to the event source. All subscribers are notified when the order is updated to the event source.
Benefits of the Event Sourcing Model
Some of the benefits of the event sourcing are:
- Auditing accuracy: Auditing is a tiring and tedious task and there is often a risk of it being incomplete or incorrect. However, with the event-driven microservice architecture in place, audit logging becomes automatic as it is carried out with every event change in the model. This makes auditing 100% accurate.
- Easy temporal queries: With the event-driven microservice architecture, the history of all the event changes is maintained by the application itself. This makes implementing temporal queries simple.
- Simple reports: Generating a complex business report takes up a lot of time and energy. An event-driven microservices architecture makes the task of generating reports simple by providing all the historical data required.
Conclusion
Microservices must communicate using an inter-process communication mechanism. In this article, we have learned about event sourcing of event-based inter-service communication.
