What is event sourcing?
Quick Answer
Instead of storing an entity's current state and overwriting it on every change, event sourcing stores the full sequence of events that happened to it (OrderPlaced, ItemAdded, OrderShipped); current state is derived by replaying them. It gives a complete audit trail for free and the ability to answer “what did this look like at time T”, at the cost of real complexity.
Rather than storing “the order currently has these five fields set to these values” and overwriting that row on every update, event sourcing stores every event that happened — order placed, item added, discount applied, order shipped — as an immutable, append-only log, and the current state is just what you get by replaying those events in order. The big win is you get a complete, truthful audit trail automatically, and you can reconstruct what anything looked like at any point in history. The costs are real, though: you usually pair it with CQRS so you have a fast read model built by projecting the events, you need snapshots so replaying a long-lived entity doesn't mean reading its whole history every time, and it's a genuinely harder mental model than CRUD. I'd only reach for it where the history itself is valuable business data, like accounting or compliance-heavy domains.
- Often paired with CQRS: events are the write-side source of truth, a separate read model (a plain table) is rebuilt/projected from them for fast queries.
- Snapshots periodically cache the derived state so replaying doesn't mean reading millions of events from the start.
- Events are immutable and append-only — you never edit history; a correction is itself a new event.
- Real costs: schema evolution of old events, eventual consistency of projections, and it's genuinely harder to reason about than CRUD — reserve it for domains where the history itself has business value (finance, audit-heavy systems), not by default.