Event Sourcing

framework · computer science · organizing-schema

Persist state as an immutable sequence of events rather than current snapshots.

Event Sourcing is an architectural pattern in which the state of an application is determined by a sequence of immutable events stored in an append-only event store, rather than by mutable records reflecting the current state. To compute current state, the application replays events from the beginning (with snapshots as optimization). The pattern was articulated by Greg Young and Martin Fowler in the mid-2000s, with deep antecedents in financial accounting (the general ledger as event log), version control systems, and database write-ahead logs that have always recorded changes as events. The benefits include complete audit trail (every change is preserved with timestamp and context), temporal queries (what was the state at any past time?), event replay for debugging or new use cases, and natural integration with event-driven architectures. Costs include schema evolution complexity (events written in one format must be readable indefinitely), replay performance for systems with many events (mitigated by snapshots), and substantial cognitive load for developers used to current-state thinking. Event Sourcing is commonly paired with CQRS but can be used independently.

Originators

Greg Young; Martin Fowler (codification); long lineage in accounting and database internals high

Year / Decade

Mid-2000s codification; Fowler's seminal article 2005 high

Primary sources

Fowler, M. (2005). 'Event Sourcing' (martinfowler.com), Young, G. (2010 onward). Various publications and presentations on Event Sourcing, Vernon, V. (2013). Implementing Domain-Driven Design (Event Sourcing chapter) high

Core components

Event store (append-only log of immutable events)
Aggregate state computed by replaying events
Snapshots as performance optimization
Event versioning and schema evolution strategies (upcasting, lazy migration)
Projections (read models built by consuming events)
Integration with CQRS (often paired)
Distinction from event-driven architecture (which uses events for communication but may not store them as system of record)

Primary use case

Domains where audit and history matter intrinsically: finance, healthcare, regulated industries, blockchain analogies; complex domains where state evolution is intricate; systems where temporal queries are valuable; foundation for some microservices patterns; integration with CQRS for high-throughput systems.

Common criticisms

Schema evolution is genuinely hard — events written years ago must remain readable, requiring careful versioning discipline that many teams don't maintain
cognitive load is high — developers must reason in terms of events rather than current state
debugging long event streams is operationally challenging
tooling support varies and many implementations have subtle correctness issues (e.g., handling concurrent writes to the same aggregate)
compliance with right-to-be-forgotten regulations (GDPR) creates fundamental tension with event-store immutability
Greg Young's caution that 'Event Sourcing is hard, do not use it unless your domain demands it' is widely quoted but often ignored
many implementations adopt Event Sourcing for systems that don't justify its complexity.

Lineage

Siblings: CQRS, Event-Driven Architecture, Domain-Driven Design