Event Sourcing

A conventional system stores accounts(id, balance) and overwrites the balance on every change. An event-sourced system stores an append-only log per aggregate: AccountCreated { initial: 100 }, PaymentMade { amount: 20 }, RefundReceived { amount: 20 }. The current balance is not stored anywhere authoritative; it is computed by replaying the events through a reducer — 100 − 20 + 20 = 100. The log is the truth; everything else is a cache of it. Writes append an event after validating the command against the replayed state; they never UPDATE.

Replay is a fold, exactly like a running total: state after event *n* is apply(state after n−1, event n). That is also why snapshots work — store the state at event 1,000 and replay only events 1,001 onward, the same trick as a Prefix Sum cached at checkpoints. Without snapshots an aggregate with a million events takes a million steps to load; with a snapshot every 100 events it takes at most 100.

Auditability for free: every change is a first-class record with a timestamp, a cause and (if you store it) an actor — regulators and support teams ask "what happened to this account?" and the log *is* the answer. Temporal queries: the state at any past moment is a replay up to that moment. Rebuildable projections: every read model (CQRS) is derived, so a projector bug is fixed by correcting the code and replaying the log into a fresh store; a new screen is a new projector run over history. Debugging by replay: copy the events of one aggregate into a test and reproduce the exact sequence that led to the bad state. Integration: the events the system needs internally are the events other services want (Event-Driven Architecture), already ordered per aggregate.

The relationship to a Kafka-style log (Kafka-Style Logs: Topics, Partitions, Offsets) is close but not identity. A partitioned log gives ordered, replayable, retained events per key — an excellent transport and a plausible event store for some systems — but an event store also needs per-aggregate reads (all events for acc1, cheaply), optimistic concurrency on append (expectedSeq), and indefinite retention; a database table with (aggregate_id, seq) as the primary key is the more common event store, with the log used for publishing.

Event versioning: events are forever, and the code that reads them changes. PaymentMade { amount } becomes PaymentMade { amount, currency } and every reducer must handle both — upcasting (transforming old event shapes into the current shape on read) is a permanent layer of the system, and a badly designed early event is a tax paid on every replay for years. Snapshots are mandatory at scale and are a cache with its own invalidation problem when the reducer changes. Queries against the log are impossible — "all accounts with balance under zero" requires a projection, which is why event sourcing drags CQRS in with it. Eventual consistency between the log and every read model is the normal state.

Deletion is the hardest. GDPR erasure requests demand removing personal data, and an immutable log is built to make removal impossible. The workable answers — crypto-shredding (encrypt each person's data with a per-person key and delete the key), storing PII outside the events by reference, or rewriting the log — are all real engineering, and none is as simple as DELETE FROM users. Finally, the mental model is unfamiliar: most developers, ORMs, admin tools and reporting systems assume current-state rows, and every one of them needs a projection to work.

Event sourcing is the right model when the history is the product: ledgers and accounting (a balance without its postings is meaningless), trading and order books, version-controlled documents, workflow engines, anything where "show me exactly what happened and why" is a core requirement rather than a nice-to-have. In those domains the events already exist in the business language — a posting, a fill, an edit — and storing them is more natural than storing the state. It also pays where audit trails would otherwise be built anyway, and in Saga Pattern orchestrators, whose state is naturally a sequence of step outcomes.

It is the wrong model for a CRUD application with a profile page, a settings form and a list of things. A conventional table with an updated_at and, where required, an audit table written by a trigger gives 90% of the audit value at 5% of the cost. The honest position: most applications need neither CQRS nor event sourcing; adopt event sourcing per aggregate where history is genuinely required, keep the rest as state, and do not rewrite a working system to it because the pattern is elegant.