Event sourcing is an architectural pattern for data persistence in which the state of a system is stored not as a mutable current-state record but as an append-only, ordered log of discrete domain events — each representing a fact that occurred at a specific point in time. Current application state is derived by replaying the event log from the beginning (or from a periodic snapshot), making the full history of state transitions a first-class, queryable artefact. This contrasts with CRUD-oriented architectures where only the latest state is stored, discarding historical change information.
Content
- Event sourcing as a named pattern was articulated by Martin Fowler in his 2005 patterns catalogue, though the underlying concept has antecedents in accounting double-entry bookkeeping (which records transactions rather than balances), database write-ahead logging (WAL), and git version control (which stores diffs and reconstructs file state by replay). The pattern gained significant adoption momentum through Domain-Driven Design (DDD) communities after Eric Evans’ 2003 book, which emphasised modelling business processes as sequences of domain events rather than entity state. The combination of CQRS and event sourcing was popularised by Greg Young through talks and writings from approximately 2010 onwards, producing a coherent architectural style for complex, high-load systems.
- An event-sourced system processes incoming commands by validating them against current state (derived from replaying the event log or a snapshot), producing one or more domain events that capture the business-meaningful facts that resulted, and appending those events to the event store. The event store is the single source of truth — a write model that is only ever appended to, never updated in place. Read models (projections) are derived views computed by subscribing to the event stream and maintaining materialised views optimised for specific query patterns. Because projections are derived, they can be rebuilt from scratch by replaying the event log, enabling schema evolution, bug fixes in query logic, and retroactive computation of new views over historical data.
- The benefits of event sourcing include complete auditability (every state change is recorded with its cause), temporal queries (reconstruct system state at any point in history), retroactive correction (replay events through corrected business logic to rebuild projections), and natural integration with event-driven architecture (events can be published to external subscribers for integration). These properties make event sourcing particularly valuable in financial systems (where regulators require full transaction audit trails), collaboration software (where optimistic concurrency and conflict resolution benefit from shared event history), and multi-agent AI systems (where replaying the sequence of agent decisions enables debugging and explanation). The trade-offs include increased storage requirements, eventual consistency of read models, and complexity in reasoning about projections and snapshot management.
- By 2024-2025, event sourcing has moved from an advanced architectural pattern to a mainstream consideration in complex system design, supported by mature frameworks including Axon Framework (Java), EventStoreDB (purpose-built event store), and Marten (PostgreSQL-based event store for .NET). Apache Kafka’s log compaction and consumer group semantics provide a production-proven substrate for event-sourced systems at scale. The pattern has found new relevance in AI agent architectures, where the sequence of tool calls, observations, and reasoning steps constitutes an event stream that enables agent memory, reproducibility, and auditable decision trails. The challenge of long event histories — requiring efficient snapshot strategies and log compaction — remains a practical engineering concern in long-running production systems.