Skip to main content
computer-science economics law

​
Event sourcing

​
Description

Event-sourcing is the architectural move of treating the log of state-changing events as the source of truth, and deriving current state by replaying the log. The diagnostic shape: instead of storing “user X has $100 in their account,” you store “user X was credited $50 at t1, debited $20 at t2, credited $70 at t3” — and compute the current balance from the events on demand (or maintain a materialized view that’s rebuildable). The history is the data; the current state is a projection. The structural payoff is full audit trail by construction (you literally can’t have current state without having every event that produced it), temporal querying for free (“what did the balance look like on day 3?”), and rebuild-from-scratch for arbitrarily-new derived views (“we now want a per-month roll-up — rebuild from the log”). The cost is operational: replay time grows with log length, materialized views must be re-derived on schema changes, and the event schema becomes part of the contract. Event-sourcing is structurally the same primitive as filesystem journaling and database WAL — but inverted in emphasis. In journaling, the log is a recovery mechanism; the in-place state is the API. In event-sourcing, the log IS the API; the in-place state is an optimization.

​
Triggers

User-initiated: User describes a system where the history of changes matters as much as current state — audit, regulatory, debugging, replay, what-if. Vocabulary cues: “event sourcing,” “CQRS,” “audit log,” “immutable log,” “log-as-truth,” “replay.” Agent-initiated: Engine notices a system that loses information when updating in place (overwrites destroy history) but where that history would be valuable. Candidate inference: “this wants event-sourcing — the events are the data, the current state is a view; consider treating the log as primary.” Situation-shape signals: Audit / regulatory requirement; need to answer “how did we get here?” queries; want to add new derived views without re-instrumenting; debugging a system where current state alone is insufficient.

​
Exclusions

  • Current state is all that matters — if no one ever asks “how did we get here?”, event-sourcing’s audit-by-construction is paying cost without earning benefit.
  • Event schema changes too often — replaying old events through new handlers requires either versioned events or schema-evolution discipline; if the schema thrashes, event-sourcing’s “rebuild from log” becomes “migrate every event, then rebuild.”
  • High-write-throughput with no value in history — every write is two writes (event + materialized view); the cost compounds.
  • Privacy-sensitive data with right-to-be-forgotten requirements — immutable logs are structurally hostile to deletion; you need cryptographic shredding or a different architecture.

​
Structure

Internal structure of event-sourcing: a table of its component slots and the concepts that fill them. = a WAL (the event log) + a set of projection functions (the materialized views) + a replay protocol (rebuild views deterministically). The structural choice is “where does each query land — on a materialized view, or on a fresh replay?” — which is the eager-vs-lazy tradeoff applied to derived state.

​
Relationships

Relationship neighborhood of event-sourcing: a graph of the concepts it connects to and the concepts it is a part of.
  • write-ahead-log — event-sourcing is WAL promoted to architectural status.
  • eager-vs-lazy — materialized views vs on-demand replay is the eager-lazy choice applied per view.
  • loop-completion — the log makes the journey legible; loop-completion gaps become diagnosable.
  • saga — sagas need event-sourced substrate to replay compensations.

​
Examples

Git · computer-science

the canonical event-sourced system; commits are events, the working tree is the materialized view, git checkout is replay.

Accounting ledgers · economics

every transaction is an immutable journal entry; balances are derived views. Centuries-old instance of the same pattern.
topics are event logs; consumers are projection processes; “Kafka as a database” is event-sourcing at infrastructure scale.
pharmaceutical batch records, financial transaction logs; the audit log IS the legal record; current state is derived.
every block is an event; the chain is the immutable log; balances and contracts are materialized views.
operation-based CRDTs are event-sourcing applied to distributed convergence.
Pat Helland’s 2015 paper “Immutability Changes Everything” (Communications of the ACM) articulated immutability-of-history as a load-bearing architectural constraint motivating the event-sourcing pattern family. Helland’s argument was that the operational realities of distributed systems — durable replication, eventual consistency, deterministic replay, and audit-by-construction — all become tractable when historical events are treated as immutable first-class data rather than as transient inputs that overwrite mutable state. Once you commit to immutability of history, the rest of the architecture (CQRS, materialized views, snapshot/replay, deterministic projections) follows from making that commitment operational.In parallel, the CQRS literature (Greg Young’s lectures and writings, Udi Dahan’s NServiceBus framework) developed the same architectural pattern from the application-architecture side: separate the command side (which produces events that mutate the log) from the query side (which reads materialized views derived from the log). The two perspectives — Helland’s substrate argument and Young/Dahan’s pattern articulation — converged on event-sourcing as the canonical architecture for systems where history matters: financial systems, audit-critical applications, complex workflow engines, and increasingly any system whose future requirements may demand new derived views over historical data.Inference: When designing a system whose future use cases are uncertain but whose historical events have intrinsic value, the architectural move is to commit to immutability of history at the substrate layer (the event log) and to derive all current and future views from it. The cost is operational complexity (replay infrastructure, schema-evolution discipline), but the payoff is that new derived views become a projection-rewrite rather than a re-instrumentation.
Kleppmann’s Chapter 11 (“Stream Processing”) reframes event-sourcing in the language of immutable append-only event logs as the system of record, with materialized views (current-state databases, search indexes, derived caches) treated as downstream consumers that can be rebuilt by replaying the log. The log is truth; everything queryable is a projection.Inference: The “log is truth, state is derived view” framing is what makes event-sourcing portable beyond DDD-style transactional services. The same shape — keep the events; derive the views — explains how Kafka-based architectures, materialized-view systems, CRDT op-based replication, and accounting ledgers share their failure-and-recovery properties. The cost (storage of a full history) buys auditability, time-travel debugging, and the ability to add new derived views without re-collecting the data they need.
Martin Fowler’s 2005 essay “Event Sourcing,” published as part of his Enterprise Application Architecture Development (eaaDev) series, is the coining work that gave the pattern its name and its canonical structural framing. The essay acknowledges prior art — accounting ledgers, the Domain-Driven Design community’s idiomatic use of event-bearing architectures — but it is Fowler’s articulation that fixed the vocabulary: the event log as append-only source of truth, current application state as a materialized view derived through a deterministic fold over history. Fowler enumerates the load-bearing properties this substrate buys — Complete Rebuild (reconstructing state from scratch by replaying), Temporal Query (state at any past moment), Event Replay (debugging or retroactive what-if), and Audit-by-Construction (history is structural, not bolted on) — alongside the principal tradeoffs (external-interaction handling during replay, event-schema evolution discipline). The essay’s worked example follows the movements of ships between ports, with arrival and departure events as the durable record and current port-occupancy as the derived view.Inference: The essay’s status as the standard citation — despite being a web essay rather than a book — is itself evidence that naming a pre-existing pattern is the load-bearing move when the pattern has accumulated independently in multiple traditions without a shared handle. Greg Young’s CQRS work paired event-sourcing with command/query separation as the architectural sibling; Eric Evans’s DDD community absorbed it as the natural durability layer for aggregates; Kleppmann’s Designing Data-Intensive Applications (Chapter 11) reframed it within the modern stream-processing lineage; the Kafka/Confluent positioning of the log-as-substrate generalized it further. Each downstream tradition cites Fowler 2005 as the canonical name-fixing act. The catalog’s pattern recurs: the structural primitive was real before naming; what the essay did was make the primitive transmissible by giving it a handle the community could share.
TextEdit’s “Revert,” Photoshop history panels — every edit is an event; the document is a projection.
Luca Pacioli’s 1494 Summa de arithmetica, geometria, proportioni et proportionalita documented the double-entry bookkeeping system that had emerged in Renaissance Italian commerce. The system is the centuries-older instance of event-sourcing: every transaction is recorded as a pair of entries (debit and credit) in journals; balances on accounts are derived from the cumulative journal entries rather than stored as primary data. The journal is the source of truth; account balances are projections. If a balance is in question, the answer is reconstructed by replaying the journal; if a new analytical view is needed (a balance sheet, an income statement, a trial balance), it is derived from the journal entries.The structural match with software event-sourcing is exact. Pacioli’s double-entry system has all the load-bearing properties of event-sourcing: immutable history (journal entries are not edited in place; corrections are made via additional entries), audit by construction (the journal preserves a complete trail), deterministic projection (the balances can be derived deterministically from the journal), and rebuild capability (new views can be derived without re-instrumenting source data). The pattern’s persistence across five centuries of commerce — surviving the transition from paper to mechanical to electronic to cloud accounting — is empirical evidence that immutable-history-plus-derived-views is a deeply load-bearing architectural pattern, not a recent software fad.Inference: When evaluating whether event-sourcing is the right architectural pattern for a system, one strong heuristic is whether the domain has independently invented immutable-history-plus-projections under any name. Accounting, legal records, scientific lab notebooks, medical records, and version-controlled source code have all independently arrived at the pattern. If the domain has this convergent shape, event-sourcing in software is recapitulating a structurally-load-bearing pattern; if it doesn’t, the pattern may be over-engineered for the actual requirements.
every measurement is an event; aggregated views (per-minute, per-hour) are projections.
Young, G., CQRS Documents (2010) — Command-Query Responsibility Segregation, the architectural sibling.