Event sourcing

Overview

Event sourcing stores every change to an entity as an immutable event in an append-only log, instead of storing only the current state. The current state is derived by replaying events: an account's balance is the sum of its Deposited and Withdrawn events. The event log becomes the source of truth.

This gives a complete audit trail, the ability to rebuild state at any point in time, and the freedom to create new read models by replaying history. The costs are more complex querying (usually requiring CQRS projections), event schema evolution, and snapshotting to avoid replaying very long histories.

When to use it

• Audit requirements: finance, healthcare, compliance.
• Domains where history matters (ledgers, order lifecycles, version control).
• Rebuilding or adding new views from past data.
• Debugging by replaying exactly what happened.

Where it shows up in interviews

Where it is used in real software

Key terms

Event

An immutable fact in the past tense (FundsDeposited).

Event stream

Ordered events for one aggregate.

Rehydration

Rebuilding state by replaying events.

Snapshot

Saved state at a version to shorten replay.

Upcasting

Converting old event versions to the new schema on read.

How it works, step by step

1. 1
   Load the aggregate

   Read the snapshot plus later events and apply them.

2. 2
   Handle a command

   Validate against current state.

3. 3
   Emit new events

   Append with an expected version (optimistic concurrency).

4. 4
   Publish events

   Projectors update read models.

5. 5
   Snapshot periodically

   For example every 100 events.

Rebuilding an account from events

Stream for account A-1

Current state is a fold over events. The rejected withdrawal is also recorded, which a state-only model would have forgotten.

Implementation

1type AccountEvent =2  | { type: "AccountOpened"; accountId: string }3  | { type: "FundsDeposited"; amountCents: number }4  | { type: "FundsWithdrawn"; amountCents: number };5 6type Account = { balanceCents: number; version: number };7 8const apply = (state: Account, event: AccountEvent): Account => {9  switch (event.type) {10    case "AccountOpened": return { balanceCents: 0, version: state.version + 1 };11    case "FundsDeposited": return { balanceCents: state.balanceCents + event.amountCents, version: state.version + 1 };12    case "FundsWithdrawn": return { balanceCents: state.balanceCents - event.amountCents, version: state.version + 1 };13  }14};15 16export async function withdraw(accountId: string, amountCents: number) {17  const events = await store.readStream(accountId);18  const account = events.reduce(apply, { balanceCents: 0, version: 0 });19  if (account.balanceCents < amountCents) throw new Error("Insufficient funds");20  // Optimistic concurrency: fails if another writer appended since we read21  await store.append(accountId, [{ type: "FundsWithdrawn", amountCents }], { expectedVersion: account.version });22}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Changing the meaning of old events.

  Fix: Events are immutable; add new event types or versions and upcast.

• Using event sourcing for simple CRUD.

  Fix: The complexity only pays off when history matters.

• Events that describe technical changes (RowUpdated).

  Fix: Model business facts (OrderShipped).

Interview questions

Practice problems