Event Sourcing in Practice

Definition

Persisting the sequence of events that produced the current state, rather than the state itself. Current state is derived by replaying events; it is a cache of the log, not the source of truth.

Why it matters

Three capabilities come free that are otherwise expensive or impossible:

Complete audit by construction. Not a change log maintained alongside the data, which can drift or be bypassed, but the actual mechanism by which state changes. For regulated domains this is the strongest argument.

Temporal reconstruction. "What was this account's state on 3 March, as we knew it then?" is a replay to a point, which matters for reconciliation, dispute resolution and regulatory reporting.

Multiple projections from one truth. Any number of read models can be built from the same event stream, and a new one can be built later from history that predates it.

Implementation patterns

Aggregate-scoped streams with optimistic concurrency on the version — the standard structure.

Snapshots so that replaying an aggregate with a long history does not require every event.

Projections maintained asynchronously into read models, with recorded positions so they can resume and be rebuilt.

Explicit event versioning, because events written five years ago must remain readable — this is schema evolution with an unusually long compatibility horizon.

Failure scenarios

Erasure. This is the one that must be designed for at the start. A right-to-erasure request against an immutable event store has one good answer: crypto-shredding — encrypt each subject's personal data with a per-subject key and delete the key. That requires events to separate business facts (in the clear) from personal attributes (encrypted). Retrofitting that structure means rewriting the events, which is the thing event sourcing exists to avoid.

Replay with side effects. Reprocessing history through a job that sends emails or calls partners re-executes them. Jobs must be side-effect-free during replay, or effects separated into a component that is not replayed.

Unbounded growth without snapshots or archival.

Modelling technical changes as events rather than business facts, producing a stream of FieldUpdated events that carries no domain meaning and provides none of the audit value.

Industry example

The pattern's natural home is ledgers and financial systems, where the log is the domain model — a bank statement is an event stream and the balance is a projection. Data Vault modelling in analytics applies the same reasoning: insert-only satellites with time-stamped attributes, chosen specifically because regulators require demonstrable lineage of what arrived and when.

Trade-offs

Gains: complete auditability, temporal queries, multiple projections, and a natural fit for domains that genuinely think in events.

Costs: substantially more complex than storing state; queries require projections; eventual consistency between the log and read models; event schema evolution over years; erasure requires deliberate design; and the team must understand it, which is a real constraint since most engineers have not worked this way.

Interview question

Your core system is event-sourced. A customer exercises their right to erasure. The events are immutable by design. What do you do?

The expected answer is crypto-shredding, and the strong answer adds the design prerequisite: personal attributes must have been encrypted separately from business facts from the start, or erasure destroys the operational history too. Candidates who propose rewriting the stream should be pressed on what that does to consumer offsets and existing projections.