Skip to content

Introduction to Event Sourcing

This guide introduces the concept of event sourcing and explains how it differs from traditional approaches to storing application state. You'll learn what event sourcing is, when and why it can be useful, how it compares to CRUD-based systems, and in which kinds of domains it can be applied. The goal is to provide an accessible and practical introduction that helps you assess whether event sourcing might be a good fit for your own projects.

Why Event Sourcing?

Most applications today are built around the idea of storing the current state of things: a customer's latest address, the current contents of a shopping cart, or the balance of a bank account. This is typically done using CRUD operations – Create, Read, Update, and Delete – which write data directly into database tables, overwriting previous values. While this model is simple and widely adopted, it has a critical limitation: it loses the past.

When data is overwritten, the history of how and why it changed disappears. If a customer updates their delivery address, the previous one is gone. If a bug causes the wrong value to be stored, there's often no reliable way to trace what happened. As a result, debugging issues, reproducing behavior, or explaining business decisions becomes difficult – if not impossible.

Event sourcing takes a fundamentally different approach. Instead of storing only the current state, it records every change to the system as a sequence of events in an append-only log. Each event captures something that happened – something in the past, immutable and factual. These events are stored in the order they occurred, and the current state of the system is derived by replaying them from the beginning. In this model, state is not stored directly – it is reconstructed, or projected, from the accumulated events.

How Event Sourcing Works

In an event-sourced system, the source of truth is not a snapshot of the current state, but an append-only log of events. Each event represents a change that has taken place – for example, money deposited into an account, a product added to a shopping cart, or a move made by a player in a game. To determine the current state, the application replays the entire sequence of events.

Take a bank account, for example. Instead of storing a single balance value, the system records a series of events such as money deposited (50 EUR), money withdrawn (10 EUR), and fee charged (5 EUR). The account balance is not stored explicitly; it is calculated by processing these events in sequence. This approach preserves the full history and makes it easy to trace exactly what happened and when.

This process is commonly referred to as a replay: the application replays the stored events in sequence to reconstruct the current state. The ability to replay the full history is one of the key advantages of event sourcing.

Broader Use Cases

Although bank accounts are a classic example, event sourcing can be applied to a wide variety of domains. For instance:

  • Online shop: Events like product added to cart, address changed, order submitted, payment completed, or shipment dispatched represent the customer's journey. Even failed or abandoned purchases remain traceable.
  • Chess server: Events such as game opened, move made (E2 to E4), game resigned, or draw offered record the full sequence of a match, enabling replays, analysis, and cheat detection.
  • Library: Events like book borrowed, book returned, late fee charged, and user account suspended document every interaction with the library system, supporting transparency and dispute resolution.
  • Industrial application (industry 4.0): Events including sensor reading recorded (temperature: 72°C), maintenance performed, machine stopped, or error reported create a continuous timeline of operational behavior, valuable for diagnostics and optimization.

These examples demonstrate that event sourcing is not limited to financial or transactional systems. It is a general-purpose approach to capturing what happened – completely, chronologically, and in full detail.

For more information, see Use Cases.

Comparing Event Sourcing to CRUD

Event sourcing stores a chronological log of what happened, while CRUD stores only the most recent snapshot of how things are. In CRUD systems, each update overwrites the previous state. In event sourcing, each change is recorded as a new event, and nothing is lost. This makes it much easier to audit changes, understand the evolution of a system, and diagnose unexpected behavior.

However, event sourcing also requires a different mindset. Instead of asking "What is the current state?", you begin by asking "What happened to get us here?". The application becomes responsible for interpreting the event stream to produce the current state. While this adds some complexity, it also opens up new possibilities for flexibility and insight.

For a detailed explanation, see Comparing EventSourcingDB with Other Tools.

Benefits and Challenges

Event sourcing enables full traceability, reproducibility, and historical analysis. It provides a natural foundation for audit logs, time travel, and retroactive changes to business logic. It also aligns well with architectural patterns such as CQRS, where reads and writes are handled separately and can be optimized independently.

At the same time, event sourcing introduces new challenges. Events must be carefully designed and versioned, since they are immutable and live indefinitely. Replaying large event streams can become slow over time, which often calls for snapshots to cache intermediate state. These snapshots allow the system to resume replay from a later point, rather than always starting from the beginning. Legal requirements such as the GDPR's "right to be forgotten" may also require additional mechanisms for anonymization or selective data erasure.

These challenges are real, but they are solvable. In many situations, the long-term benefits—transparency, auditability, and flexibility—clearly outweigh the initial complexity.

When to Use Event Sourcing

Event sourcing is particularly valuable in systems with complex domain logic, frequently changing business rules, strong audit or compliance requirements, or a need for long-term traceability. If you've ever found yourself wishing you could go back and see exactly how and why a piece of data changed over time, event sourcing is worth exploring.

To support this architectural style, we created EventSourcingDB – a purpose-built database designed specifically for storing and querying event streams efficiently. It provides a reliable foundation for implementing event-sourced systems and integrates easily into modern software architectures.

For more information, see Why EventSourcingDB.