Event-Sourced Entity History¶
Data-architecture pattern — instantiates Identity-Bounded Change
Stores an entity's whole life as an ordered, append-only log of events and treats that log as the source of truth, reconstructing any past or present state by replaying it.
Event-Sourced Entity History records an entity not as a row that gets overwritten but as an ordered, append-only sequence of the events that happened to it — AccountOpened, Deposited, AddressChanged. Its defining move is inverting where truth lives: the current state is not stored at all, it is derived by replaying the events, so the immutable event stream itself is the entity and every state — including any past state — is a fold over that stream. Because events are only ever appended, never edited or deleted, the history is a complete, tamper-evident record by construction. Where a version control system keeps snapshots and diffs of an artifact's states, event sourcing keeps the causes of those states and treats them as primary.
Example¶
A payments system holds customer account balances. Instead of a balance column it mutates, it appends events: AccountOpened, Deposited(+\$200), Withdrew(−\$50), FeeCharged(−\$3). The balance is simply whatever those events fold to — here, $147 — recomputed on demand rather than stored and trusted.
When a customer disputes a fee, support replays the account to any date and sees the exact state and the precise event that changed it; nothing was overwritten to obscure the path. When a bug is found that mis-charged a fee, engineers do not reach in and edit the bad event — they append a compensating FeeReversed event, so the record shows both what happened and the correction. The account remains one continuing identity whose every state is reconstructable, and whose ledger cannot silently drift, because state is always re-derivable from an immutable log rather than being a number someone can quietly change.
How it works¶
- Events are the write model — appended in order, immutable, each a fact about something that occurred.
- State is a derived read model — any view (a balance, a profile) is a projection rebuilt by replaying events, and can be discarded and recomputed at will.
- Snapshots cache a fold — periodic saved states let replay start partway rather than from birth, for speed.
- Corrections are new events — mistakes are fixed forward with compensating events, never by mutating the past, which is what keeps the log authoritative.
Tuning parameters¶
- Event granularity — how fine each event is; finer events capture more intent and support more projections but grow the log and its replay cost.
- Snapshot interval — how often a folded state is cached; frequent snapshots speed reads but add storage and can mask a replay bug.
- Event-schema evolution — how the shape of events is versioned over time; strict upcasting keeps decades-old events replayable but adds migration work.
- Projection set — how many read models are derived from the one log; more projections serve more queries but every one must stay rebuildable.
- Retention — whether the full log is kept forever (a true source of truth) or truncated behind snapshots (faster, but deep history is sacrificed).
When it helps, and when it misleads¶
Its strength is that it delivers a perfect audit trail and time-travel almost for free: "how did we arrive at this state" is always answerable, derived views can be rebuilt or bug-fixed by replay without losing the underlying truth, and no state can drift away from its own history. It shines exactly where accountability and reconstructability are non-negotiable — finance, compliance, anything that must survive an audit.
Its authority is only as strong as the log's immutability. The cardinal sin is editing or deleting past events to "clean up" data, which turns the source of truth into a fiction. Subtler failures include non-deterministic replay — events whose handlers call a now-changed external service, so the same log folds to a different state than it once did — and the plain cost that an ever-growing log makes replay slow and schema evolution a standing tax. The discipline that keeps it honest is to never mutate history but record corrections as compensating events[n1], keep event handlers deterministic, and version event schemas explicitly.
How it implements the components¶
Event sourcing fills the append-only-record components of the archetype — the ones a log-as-truth store produces:
event_log— the ordered, append-only stream of events is the mechanism's core artifact and its representation of the entity.source_of_truth_reference— that log, not any stored snapshot, is the authoritative reference from which every state is derived.audit_trace— because events are immutable and complete, the log is a by-construction audit trail of everything that happened.
It does not version an artifact's states as diffs or expose branches and tags (that's Version Control System), nor judge whether the accumulated events still make it the same governed entity (that's Identity Continuity Review).
Related¶
- Instantiates: Identity-Bounded Change — it supplies the immutable, replayable history that lets an entity's identity rest on evidence rather than on a mutable current state.
- Sibling mechanisms: Version Control System · Document Revision History · Persistent Identifier Resolver · Identity Continuity Review · Replacement or Fork Decision Record · Conservation Treatment Record · Chain-of-Custody Record · Legal Amendment Record · Policy Amendment Register · Split/Merge Change Log
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Event-Sourced Entity History operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it stores an entity's whole life as an ordered, append-only log of events and treats that log as the source of truth, reconstructing any past or present state by replaying it.
Independent corroboration: The frozen evidence defines Event-Sourced Entity History as 'Stores an entity's whole life as an ordered, append-only log of events and treats that log as the source of truth, reconstructing any past or present state by replaying it', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Event-sourcing architecture cohered an entity as an append-only stream of domain events from which any past or present state is reconstructed.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] In event-sourced systems, a recorded event is never edited or deleted; a mistake is corrected by appending a new compensating (or reversing) event that captures both the error and its correction. This preserves the log's standing as an immutable source of truth while still letting the derived state be made right. ↩