Event Sourcing

Core concept

A normal database stores the current answer and throws away the question. Event Sourcing inverts that: the only source of truth is an ordered, append-only log of facts that already happened — and current state is a derived value, computed by replaying that log.

The shift is small in code and large in consequence. UPDATE accounts SET balance = 300 destroys information: you now know the balance and nothing about how it got there. Appending MoneyWithdrawn(200) instead keeps the balance obtainable and keeps the history, the cause, the ordering, and the timestamp. Nothing is ever mutated; nothing is ever deleted.

Key components

A fifth piece is operational rather than conceptual: the snapshot. Replaying 4 million events to answer one balance query is not viable, so you periodically persist "state as of sequence N" and replay only the tail after it. Snapshots are a cache — they must always be re-derivable from the log, never authoritative.

How it works

1. A command arrives“Withdraw 200 from account A.” A command is a request — it is imperative, it can be refused, and it is not yet a fact.
2. Load the aggregateReplay account A's events (from its latest snapshot forward) to rebuild just enough state to decide. Balance = 300.
3. Validate, then emitBusiness rules run against that state. If 200 ≤ 300, emit MoneyWithdrawn(200). If not, reject the command — and write no event at all.
4. Append with an expected versionAppend at sequence N+1, asserting the stream is still at N. If a concurrent writer got there first, the append fails and the command retries against fresh state. This is optimistic concurrency with no locks.
5. Fan out to projectionsSubscribers consume the new event and update their read models — balance table, statement view, fraud index. Each projection tracks its own position in the stream, so they can lag, catch up, or be rebuilt independently.
6. Query the projection, never the logReads hit the shaped read model. The log is for writing truth and for replay; it is a terrible thing to query directly.

# the entire read path, conceptually
events = store.read("account-A", from=snapshot.seq)
state  = snapshot.state
for e in events:
    state = apply(state, e)     # pure function, no I/O

# apply is a total function over event types
def apply(s, e):
    if e.type == "MoneyDeposited":  return s + e.amount
    if e.type == "MoneyWithdrawn":  return s - e.amount
    return s                     # unknown event: ignore, don't crash

Where it actually earns its cost

• Banking & ledgers. Double-entry accounting has been event sourcing for 700 years. Balances are derived; the journal is truth. Regulators ask "prove this figure" — the log is the proof.
• Git. Every commit is an immutable event; your working tree is a projection. git checkout <sha> is temporal query, and reflog is the log outliving the state.
• Order fulfilment & logistics. An order's life is genuinely a sequence of facts — placed, paid, picked, shipped, returned. Modelling it as one mutable status column loses the story the business needs.
• Collaborative editors. Figma, Google Docs, and CRDT-backed tools ship operations, not documents. Undo, presence, and offline merge fall out of having the operation history.
• Debugging production. Replay the exact event sequence that caused a bug into a fixed version of the code. Not a reconstruction — the real input.