Event sourcing is a pattern for storing the state of an application not as a snapshot of current values, but as the full history of changes that produced it. Martin Fowler, in his Event Sourcing article, states the idea in a single line: “Capture all changes to an application state as a sequence of events.” Rather than overwriting a record when something changes, the system appends an event describing what happened. The events, taken together as an ordered log, become the authoritative record of everything the system has done.
The defining property of this approach is that current state is derived, not stored. Fowler explains that a system can “discard the application state completely and rebuild it by re-running the events from the event log on an empty application.” Because every change is captured as an event, and because “all changes to the domain objects are initiated by the event objects,” the present can always be reconstructed by replaying the past. The familiar analogy is a version-control system or an accountant’s ledger: you never erase an entry, you record a new one, and the balance is the sum of all entries.
Keeping the entire history unlocks capabilities that a state-only design cannot offer. Temporal queries can ask what the state was at any past moment, simply by replaying events up to that point. A complete audit trail comes for free, since the log is the record of every change and why it occurred. Bugs can sometimes be repaired by correcting the event-handling logic and replaying, and entirely new read models or projections can be built after the fact by replaying the existing events through new code.
The pattern carries real costs. The event log grows without bound and may need snapshotting so that rebuilds do not have to replay from the very beginning. Schema evolution is delicate, because old events were written under old assumptions and must remain interpretable forever. External side effects — sending an email, charging a card — are problematic during replay, since replaying a stored event must not re-fire those actions. These concerns make event sourcing a deliberate architectural commitment rather than a default.
Event sourcing pairs naturally with Command Query Responsibility Segregation: the append-only event log is the write side, and one or more read models are projected from the events to serve queries efficiently. It also underlies much of modern event-streaming practice, where a durable, replayable log of events is the central abstraction. Used where its history-first model genuinely fits, event sourcing turns the change log itself into the system of record.