The CRUD Problem
Most applications use a "CRUD" (Create, Read, Update, Delete) data model. Think of it like a whiteboard: when you want to update something, you erase the old value and write the new one. Simple, but the old value is gone forever.
- Action: You update your user profile address from "New York" to "London".
- Database: Overwrites the old value. The row now says "London".
The Problem: The history is lost. You know where the user is now, but you don't know when they moved, or where they lived before. The database has amnesia — it only remembers the present. This becomes a serious liability when you need to audit changes, debug unexpected state, or reconstruct what happened during an incident.
The Event Sourcing Solution
Event Sourcing changes the fundamental way we store data. Instead of storing the "Current State," we store the Sequence of Events that led to that state. Current state becomes a derived value — something you calculate, not something you store directly.
Think of it like a bank's accounting ledger:
- You don't erase the "Balance" cell and write a new number.
- You record a new transaction:
-$50 (Groceries). - The current balance is simply the sum of all past transactions.
If you store the events, you can derive the state at any point in time. You never delete data; you only append new facts. This append-only property is what makes Event Sourcing so powerful — and so different from CRUD.
Why This Matters Beyond Auditing
Event Sourcing is not just about keeping a log. The event stream becomes the single source of truth for your system. Read models, analytics pipelines, notification services, and audit trails all derive from the same stream. This means you can add new consumers of historical data without touching the original system — a capability that is impossible in a CRUD model where the past is already gone.