Event Sourcing

Table of Contents

🟠 P1 — store events, not state; the append-only log as source of truth

Problem #

Traditional databases store current state. You can see what a user’s balance is, but not how it got there. For auditing, debugging, and temporal queries, you need the full history of mutations.

Mechanism #

Traditional:  UPDATE accounts SET balance = 150 WHERE id = 123
              → Previous balance (100) is gone forever

Event-sourced:
  Event 1: AccountCreated  {id: 123, balance: 0}
  Event 2: DepositMade     {id: 123, amount: 100}
  Event 3: DepositMade     {id: 123, amount: 50}
  → Current state = replay all events = balance 150
  → Can reconstruct state at any point in time

Key Trade-offs #

Dimension	Benefit	Cost
Auditability	Complete history of every change	Storage grows unboundedly
Debugging	Replay events to reproduce bugs	Replay can be slow for old entities
Temporal queries	“What was state at time T?”	Query complexity (need projections)
Schema evolution	Old events may not match new schema	Event versioning required

Instinct #

Event sourcing is a natural fit for financial systems (every transaction is an event, auditability is a legal requirement) and systems where the history IS the value (version control, audit logs, analytics). It’s overkill for simple CRUD apps. Always pair with snapshots (periodic state checkpoints) to avoid replaying millions of events on read.

DDIA 2e Reference #

Chapter 11: Event sourcing, immutability advantages
Chapter 12: Derived data from event logs