Event Sourcing: Events, Immutability & State

Event Sourcing persists application state as a sequence of immutable EVENTS describing everything that has happened, rather than storing only the current state directly. Current state at any point is derived by replaying that event sequence -- it's a computed view, not the primary stored fact.

Events vs. Traditional CRUD

TRADITIONAL: UPDATE accounts SET balance = 500 WHERE id = 5
(overwrites the previous value -- history of HOW you got to 500 is lost)

EVENT SOURCED:
  AccountOpened { accountId: 5 }
  Deposited { accountId: 5, amount: 200 }
  Deposited { accountId: 5, amount: 300 }
(current balance = 500 is DERIVED by replaying/summing these events)

# Events are named in the PAST TENSE -- immutable facts about what
# already happened, distinct from a command ("Deposit") which
# could still be rejected before becoming a recorded event

Immutability & Compensating Events

Past events are never edited or deleted -- correcting a mistake means recording a NEW event (a 'compensating event') that corrects the effect of the earlier one, preserving an honest record that the mistake happened and was fixed, rather than rewriting history.

Snapshots for Performance

Replaying 10,000 events on every state lookup would be slow. A snapshot (a saved current-state representation taken periodically, e.g. every 100 events) lets reconstruction start from the most recent snapshot and replay only the events since -- without ever discarding the full historical log itself.

Event Ordering Matters

State is derived by replaying events IN ORDER -- processing a 'Withdrew $100' event before the 'Deposited $200' it should follow could produce an incorrect intermediate state. Correct ordering, especially in distributed systems, is a genuine correctness concern.