What is Event Sourcing Pattern?

The Event Sourcing Pattern used to capture and persist state changes (events) as a sequence of immutable records. Instead of storing just the current state of an entity, this pattern stores the entire history of events that led to the current state.

This pattern helps us with a complete audit trail, enables complex event processing, and improves consistency. We can also implement time travel debugging or replaying events for analytics purposes.

A quick Example, I can think of is creating a release for Production. Starting from creating the release version, Getting Approvals by presenting to stakeholders, Completing Code Quality Checks, assigning teams to help with deployment and then Deploying on day of deployment. If any step fails, we can move back and forth and reach the current state.

For example, if the user changes the email address in our application, the user email field updated with the new one. So, email information overrides the existing field of email in the user table. By this way, we always know the latest status of the data. But by Implementing Event Sourcing Pattern we don’t override existing data we add new Record for same user under Email Address And we point it as latest. And also, we store the Event that User has updated the Email Address.

Another Example, Ride booking, Book Ride, Ride Booked, Ride Started, Ride Ended.

Multiple microservices can collaborate to handle requests, and they communicate through events. These events can result in a change in state (data). Storing event objects in the order in which they occur provides valuable information on the current state of the data entity and additional information about how it arrived at that state.

Architecture: In distributed, event-driven microservices applications, commands represent the instructions or requests sent to a service, typically with the intent of initiating a change in its state. The service processes these commands and evaluates the command’s validity and applicability to its current state. If the command runs successfully, the service responds by emitting an event that signifies the action taken and the relevant state information.

Event Store: Events are logged into an immutable, append-only, chronologically ordered repository or data store known as the event store. Each state change is treated as an individual event object. An entity object or a data store with a known initial state, its current state, and any point-in-time view can be reconstructed by replaying the events in the order of their occurrence.

The event store acts as a historical record of all actions and state changes and serves as a valuable single source of truth. The event store publishes the events it stores, and the events can be filtered and routed to the appropriate processor for subsequent actions.

Event Generation: Every change in the state of a domain object (entity) is captured as a distinct event. For example, in an e-commerce system, events could be “Order Placed,” “Order Shipped,” “Payment Received,” etc.

Event Storage: These events are stored in an event store, which is a specialized database designed to handle a large number of immutable events efficiently. The event store is append-only, meaning once an event is stored, it cannot be changed.

Reconstruction: To reconstruct the current state of an entity, the system replays all events related to that entity in sequence. This ensures that the state is always consistent and up-to-date.

Event Handling: Events can trigger additional processes or actions within the system, often through event handlers or projections. This allows for decoupled and scalable processing.

The event sourcing pattern is frequently used in applications that require a point-in-time recovery, and also when the data has to be projected in different formats by using a single source of truth.

Events are immutable and can be stored using an append-only operation. Events don’t directly update a data store. They’re simply recorded for handling at the appropriate time. Events are simple objects that describe some action that occurred. The append-only storage of events provides an audit trail that can be used to monitor actions taken against a data store. The event store raises events, and tasks perform operations in response to those events. This decoupling of the tasks from the events provides flexibility and extensibility.

Thank you for reading. you can follow me on LinkedIn and Medium