What is event sourcing?

Event sourcing is the pattern that records every change to an application's state as a sequence of events, instead of storing only the latest value. The idea is as old as accounting ledgers, and the reference description for software is Martin Fowler's, from 12 December 2005. An order, in a conventional system, is a row updated in place: it changes status, changes delivery address, and the history of how it got there disappears with every subsequent write, overwritten by the latest value. With event sourcing that row does not exist: what exists is a log of immutable, ordered events (created, paid, shipped, returned) and the current state is obtained by replaying the log from the start, one event at a time, instead of reading it already assembled from a table. The log is the source of truth, the state the application shows is a consequence computed at read time, not a fact stored elsewhere and therefore free to drift from it.

See also: CQRS · Splitting the model that writes data from the one that reads it, instead of using a single model for both jobs.

What it buys, and what it costs

Fowler lists three capabilities that follow from the log. Complete rebuild: from an empty system, the current state is regenerated simply by replaying every event. Temporal query: every event carries its own moment, so one can ask what the state was at any past instant. And corrected replay: an event processed with the wrong logic is reversed and the sequence replayed with the correct logic, instead of hand-fixing a record that is now inconsistent. The cost has two sides. Outward, a system that sends emails or issues payments cannot tell a replay from a genuine run, so it has to be isolated from the log; and retrofitting event sourcing onto an existing system is "very hard", Fowler warns, because the prior history was never captured as events. Inward, the event format has to evolve over years while old events stay readable (see schema evolution), and anyone who wants the current state without replaying the whole log needs a projection: an already computed, kept-up-to-date view, which is exactly the job CQRS assigns to the read side. The two patterns often travel together but stay distinct: CQRS can exist without event sourcing, with the write side on an ordinary relational database.

An enterprise example

An Italian industrial warehouse runs orders and stock on a system that updates the available quantity in place on every movement. A customer disputes a balance, claiming ten units were returned and never credited. With a balance updated in place, reconstructing what happened means cross-checking emails, delivery notes and whoever's memory handled the order. With a log of events (received, picked, shipped, returned, reversed) the exact sequence is already there, with a date and an operator on each step, and yesterday's balance comes from stopping the replay at the right point instead of relying on an overnight backup.

Why it matters for decision makers

Event sourcing pays for itself where traceability is a requirement: accounting, credit balances, billing, anywhere an auditor or a client can ask "how did we get to this number" and the answer has to exist. It is over-engineering almost everywhere else: on a CRUD run by a small team with no audit obligation, the log adds a projection to maintain and a format to evolve for years, against a benefit nobody asked for. The useful question before adopting it is whether somebody will genuinely need to reconstruct the past, or correct it with logic different from the one it was first written with.