What is Event Sourcing

Event sourcing is a pattern where the state of a system is stored as an ordered sequence of immutable events rather than as the current state in a mutable database. The current state is derived by replaying all events from the beginning.

How it works

Instead of storing "Order #42: status = shipped, total = $99," you store the events:

1. OrderCreated { id: 42, items: [...], total: 99 }
2. PaymentReceived { order_id: 42, amount: 99 }
3. OrderShipped { order_id: 42, tracking: "1Z..." }

To get the current state of order #42, you replay these three events. To get the state at any point in time, you replay events up to that timestamp.

Events are append-only — they are never modified or deleted. This provides a complete, auditable history of every change.

Connection to CQRS

Event sourcing is often paired with CQRS. The event log is the write model. Projections — materialized views built by processing the event stream — form the read models. Need a new view of the data? Build a new projection and replay the events.

Why it matters

Event sourcing provides a complete audit trail (every change is recorded), enables temporal queries (what was the state at time T?), and supports replaying events to build new projections. It is valuable for domains where history matters: financial systems, compliance, and complex business workflows.

The tradeoff is complexity. Event stores are harder to query than relational databases. The event schema must evolve carefully. Replaying millions of events can be slow without snapshots.

For how event sourcing works with CQRS, see How CQRS Works.