Event sourcing is a pattern used in software design that involves persisting the state of an application or system as a sequence of immutable events, rather than storing the current state directly. Essentially, every change to the state of the system is recorded as an event, and the current state of the system is derived by replaying these events.

In event sourcing, events are the fundamental building blocks of the system. Each event represents a change in the state of the system that has occurred at some point in the past. Events are stored in an event log or journal, which is an append-only data structure that records all events in the order in which they occurred. The event log becomes the source of truth for the system’s state.

When a new event is received, it is appended to the end of the event log. To reconstruct the current state of the system, all events in the log are replayed, in order, from the beginning of time. This means that the current state of the system is always the result of applying all events in the log.

Event sourcing has several benefits, including:

• Auditability: Because the event log captures all changes to the system, it is easy to audit the system and trace the history of any particular piece of data.
• Scalability: Because the event log is append-only, it is highly scalable and can handle high volumes of data.
• Flexibility: Because events are immutable and can be replayed, it is possible to add new features to the system or change the behavior of existing features without affecting the past events.

Event sourcing is often used in conjunction with other patterns, such as Command Query Responsibility Segregation (CQRS) and Domain-Driven Design (DDD), to build complex, scalable systems.

Example

Let’s consider a simple banking application that allows users to transfer money between their accounts. In an event sourcing approach, we would model this transaction as a series of events, rather than a traditional CRUD-style update.

Here’s an example of how this might work:

1. User A transfers $100 to User B’s account.
2. The system generates an “Account Debited” event with the details of the transaction (e.g., the account numbers and the amount transferred).
3. The system generates an “Account Credited” event for User B’s account.
4. Both events are stored in an event store, which acts as the system of record for all transactions.
5. If the system needs to determine the current balance of either account, it can do so by replaying the events from the event store and calculating the balance based on the events.

In this way, event sourcing allows us to track the history of all transactions in the system, and provides a clear audit trail of what happened and when. It also provides a way to recover from system failures, since we can simply replay the events to restore the system to its previous state.

In this example, the event sourced aggregate would be the account object that is responsible for generating the events in response to a transfer request.