Event Sourcing models every change in the state of an application as an event object. The events are recorded in an append-only store. Application generates a series of events that capture the change that it has applied on data and these events are durably stored in sequence they were applied. The state itself is not saved in events, but it can be reconstructed by replaying the events.

The events are persisted in an event store that acts as the source of truth or system of record (the authoritative data source for a given data element or piece of information) about the current state of the data. The event store typically publishes these events so that consumers can be notified and can handle them if needed. Consumers could, for example, initiate tasks that apply the operations in the events to other systems, or perform any other associated action that is required to complete the operation. Notice that the application code that generates the events is decoupled from the systems that subscribe to the events.

Event Sourcing is like CQRS in approach. However, unlike commands in CQRS which define what is to be changed in an object, events contain data about a change that has been applied on state. Generally, CQRS and Event Sourcing work together. A command can change the data and the change can generate events to which other components of system can react. A practical example of this pattern is bank account statements, in which you can see the modification of account balance (state) by various transactions (events). Another practical example of application of this pattern is version control systems such as Git:

The preceding diagram presents a high-level architecture of Event Sourcing pattern. The Event Queue can be implemented with messaging oriented middleware, which is a software or hardware infrastructure supporting the sending and receiving of messages between distributed systems. The Event Queue can receive events and send it to the Event Store.

The Event Store is an append-only store that receives all events from the Event Queue and appends them to the existing list of events. The event store can be used to reconstruct the state in case of failure or when you want to replay the events leading up to a desired state.

The Event Store can publish the saved events to which one or more Event Handlers can subscribe. The Event Handlers contain business logic which reacts to events. They can invoke commands that can make changes to the state. For example, a seat booking event handler can reserve seats in a scheduled flight and decrements the number of available seats.

Replaying events from beginning every time can lead to slow performance. Therefore, application can maintain Snapshots which contain the current state. Periodically the data in snapshot can be updated to stay in line with the new events. However, snapshot is an optional feature and may not be implemented if the application does not generate a lot of events.

To apply Event Sourcing pattern, look out for scenarios that involve auditing, reconstruction of historical state, or following a series of events such as bookings to an account.

Event Sourcing works well in concert with CQRS pattern. To implement this pattern through Microservices, it is recommended that your Microservices are built using the Event Driven Architecture (EDA).

EDA models the communication between Microservices through events. In this architecture, each service is an event receiver and an event publisher. A Microservice that is interested in the processing outcome of another service can register to receive events from that service. This allows for loose coupling between services and easy modification of the workflow without affecting multiple Microservices. For example, for an e-commerce, this architecture would model the workflow as follows:

• The Order Service creates an Order in a pending state and publishes an OrderCreated event.
• The Payment Service receives the event and attempts to charge payment instrument for the order received. It then publishes either a PaymentSucceeded event or a PaymentFailed event.
• The Order Service receives the event from the Payment Service and changes the state of the order to either approved or cancelled.

Following is a diagram of how CQRS and Event Sourcing patterns can be combined: