Traditional databases store the current state of data. When you update a customer's address, the old address is gone. The database tells you what is, but not how it got there.

Event sourcing takes a fundamentally different approach. Instead of storing current state, you store a sequence of events that describe everything that happened. The current state is derived by replaying these events. Nothing is ever deleted or updated in place. Every change is recorded as a new event.

In this chapter, you will learn:

State-Based vs Event-Sourced

Let us compare the two approaches with a concrete example: a shopping cart.

State-Based Approach

The database stores the current cart contents. When the user adds an item, you update the row. When they remove an item, you update the row. History is lost.

Event-Sourced Approach

Every action is stored as an immutable event. Current state is derived by replaying all events.

Key Differences

Event Stream Structure

What is an Event?

An event is an immutable record of something that happened.

Event Structure:

Event Streams

Events are grouped into streams, typically one per aggregate or entity:

Storage Technologies

Rebuilding State from Events

In event sourcing, the database doesn’t store “the order.” It stores everything that happened to the order.

To get the current order, you derive it by replaying those events.

This process is usually called:

Same idea: events go in, state comes out.

Basic Projection

Think of an aggregate (like Order) as a pure function of its history:

CurrentState = fold(apply, initialState, events)

Where apply(state, event) is your event handler.

Replay Process

When the system needs the current state of order-456, it does something like this:

This is why event ordering and versioning matter. You’re rebuilding reality by replaying history.

Practical Example

Snapshots

Replaying events is elegant, but it has a performance cliff.

If an aggregate has thousands of events, rebuilding it on every load becomes expensive.

The Problem

An order with heavy editing history (item changes, address updates, partial refunds) might have 10,000 events.

Loading that order means:

That’s too slow for interactive systems.

Snapshot Solution

A snapshot is a saved checkpoint of the aggregate state at a particular event version.

Loading with Snapshots

To load current state:

With 10,000 events, snapshot at 9,900:

Snapshot Strategies

Best practice:

Handling Commands

In event sourcing, commands do not directly modify state. They produce events that are then stored.

Command Processing Flow

Optimistic Concurrency

Because the event store is append-only, concurrency control is usually done with versions.

Each aggregate stream has a version:

Example

Then user B:

Why this matters

Event Schema Evolution

Unlike traditional databases where you migrate data, events are immutable. How do you handle schema changes?

The Challenge

Upcasting

You keep old events as-is, but when reading you transform them into the latest shape.

Why it’s popular

Event Versioning

Include version in event type.

Copy-Transform

For complex migrations, copy events to new stream with transformation:

Event Sourcing with CQRS

Event sourcing pairs naturally with CQRS:

Write Side: Commands processed by aggregates, events stored in event store.

Read Side: Events projected into multiple read models optimized for queries.

Benefits of the Combination

Advantages of Event Sourcing

Event sourcing flips the storage model:

Instead of persisting order.status = "shipped", you persist: OrderCreated → ItemAdded → PaymentReceived → OrderShipped

That shift buys you several powerful capabilities.

Complete Audit Trail

Every change is recorded. You can see exactly what happened, when, and often why.

Example: Order 456 history

Temporal Queries

Because you have the full event stream, you can answer questions about past states.

Debugging and Replay

When something goes wrong, event sourcing gives you the exact sequence of steps that produced the outcome.

Rebuild Projections

In event sourcing, read models are typically projections derived from events. The huge advantage is:

If you need a new read model, you can build it by replaying history.

Scenario: You want a new dashboard showing order analytics.

Solution

This makes new features safer: you don’t mutate your “source of truth,” you derive from it.

Disadvantages of Event Sourcing

Event sourcing is powerful, but it’s not “free.”

Complexity

You’re no longer saving objects. You’re appending facts and reconstructing state.

Traditional:

Event Sourced:

More concepts to understand: events, aggregates, projections, snapshots.

Eventual Consistency

In most architectures, you write events to the event store and then update read models asynchronously.

So the timeline looks like:

That gap might be milliseconds—or seconds—or longer during incidents.

You must design for “write succeeded, read still stale.”

Event Schema Evolution

Events are meant to be immutable: once recorded, they represent history.

If you don’t plan for this early, schema evolution becomes painful later.

Storage Growth

In a state-based system, you store the latest record. In an event-sourced system, you store the full history.

This is not necessarily a dealbreaker but you still need:

Query Complexity

Events are optimized for appending and replay, not ad-hoc querying.

State-based

Event-sourced

Every query pattern needs a projection.

When to Use Event Sourcing

Good Fit

Poor Fit

Domain Indicators

Consider event sourcing when:

Avoid event sourcing when:

Real-World Examples

Banking and Finance

Banks have used this pattern (the ledger) for centuries.

E-Commerce Order Management

Every order state change is an event: created, paid, shipped, delivered, returned. Enables: order tracking, analytics, customer service history.

Healthcare

Patient records as events: visits, diagnoses, prescriptions, tests. Enables: complete medical history, temporal queries, compliance.

Summary

Event sourcing stores all changes as immutable events rather than overwriting current state:

Event sourcing represents a fundamentally different approach to data persistence. It trades some simplicity for powerful capabilities around history, auditing, and temporal analysis.