Event Sourcing

Current-state systems are easy to query, but every update destroys context unless you build separate audit tables. If a booking changed from PENDING to CONFIRMED toCANCELLED, the final row may not tell you who changed it, which payment event arrived first, or what the system believed at 10:05. Event sourcing makes the history the primary data.

Events are usually grouped by aggregate: one account, order, booking, cart, or document. Each stream has a monotonically increasing version. Commands validate against the current aggregate state, then append one or more new events if the command is allowed.

account-42 event stream:
  v1 AccountOpened     { ownerId: "u1", currency: "USD" }
  v2 MoneyDeposited    { amountCents: 10000 }
  v3 MoneyWithdrawn    { amountCents: 3000 }
  v4 MoneyWithdrawn    { amountCents: 2000 }

replay(events):
  state = { opened: false, balanceCents: 0 }
  for event in events ordered by version:
    if event.type == "AccountOpened":
      state.opened = true
      state.currency = event.currency
    if event.type == "MoneyDeposited":
      state.balanceCents += event.amountCents
    if event.type == "MoneyWithdrawn":
      state.balanceCents -= event.amountCents
  return state

result: { opened: true, balanceCents: 5000, currency: "USD" }

Optimistic concurrency

Appending usually includes an expected version: "appendMoneyWithdrawnonly if the stream is still at version 4". If another writer appended version 5 first, the command reloads, checks business rules again, and retries or rejects. This protects invariants without locking the entire system.

Replaying ten events is cheap. Replaying ten million events for a hot aggregate on every request is not. A snapshot stores the derived state at a particular event version. To load the aggregate, read the latest snapshot and replay only events after it.

snapshot:
  aggregateId: account-42
  version: 100000
  state: { balanceCents: 918273, status: "OPEN" }

loadAggregate(account-42):
  snapshot = readLatestSnapshot(account-42)
  events = readEventsAfter(account-42, snapshot.version)
  return replayFrom(snapshot.state, events)

• Snapshot every N events: simple and predictable, common for aggregates with long histories.
• Snapshot by cost: create one when replay time exceeds a threshold rather than every fixed count.
• Snapshot is cache, not truth: if a snapshot is corrupted, you can rebuild it from the event stream.

Event-sourced write models are not optimized for arbitrary queries like "show the last 50 orders for this customer". The common pairing isCQRS: commands append events to the write model, and asynchronous projectors build read models tailored to screens, search, analytics, and APIs.

command API:
  CancelOrder(orderId)
    → validate by replaying order stream
    → append OrderCancelled v12

projectors consume events:
  OrderCancelled
    → update orders_by_customer table
    → remove shipment task
    → update support dashboard
    → publish integration event to Kafka

Those projection updates are often delivered through a log such as Kafka or through an outbox/CDC pipeline. Read models can lag behind the write stream, so user experience must handle eventual consistency with loading states or read-your-writes shortcuts.

Event sourcing shines where the history is valuable, not just the final value. Financial ledgers, booking systems, inventory movements, workflow engines, source control, collaboration logs, and payment systems all benefit from a trustworthy sequence of facts.

• Audit: every decision can point to the events that caused it, including who initiated commands and when.
• Time travel: replay up to event version 123 to answer what the system believed at that moment.
• Debugging: copy one aggregate stream into a test and reproduce a bug exactly.
• Integration: downstream services can consume the same domain events that created the state.

Event sourcing is a commitment. Events are long-lived APIs to your own future code. You cannot casually rename fields or reinterpret old facts without migration or upcasting. Teams also have to operate projectors, handle duplicate delivery, monitor lag, and explain eventual consistency to product owners.