According to the Event Sourcing pattern, to capture all changes to the system states as a
sequence of events is known as event sourcing.

We can say that all information and data in the system is persisted in the form of events, and an event is nothing but a piece of information to tell the system about something that has occurred, such as domain creation, update, and deletion. The generated events are immutable by nature, you cannot modify or delete them. So, it is totally based on the occurrences in the system, if something has occurred in the system, the events will be triggered.

The main concept behind the Event Sourcing pattern is capturing every change of the state of an application during processing into an event object. These event objects are stored in the sequence to be triggered in the same scope as the application-processing scope.

Suppose we have a distributed application with two microservices, Account and Customer for example, and we want to trigger a notification to the customers for any new customer added or any modification to the data of customers. And also we want to trigger a mobile notification when any change happens to the accounts associated with customers. Let's see the following diagram:

In this example, as you can see in the preceding diagram, we have introduced the Event Sourcing pattern, and added a step to this process. Now the service creates an event object to record the change and processes it to update the customer and account.

We have seen an Event Sourcing-based system with Command Query Responsibility Segregation, which has two parts, command and querying. The command query is all about writing databases, and querying is all about reading data for the frontend. But having separate models raises questions about the data consistency for those models which are used in the frontend. Let's see how to maintain data consistency in the distributed event-driven system using Eventual consistency.