Event Sourcing

What is event sourcing?

Event sourcing stores application state as an append-only sequence of events — “account opened,” “deposited $100," "withdrew$30” — rather than as current values in mutable rows. Current state is derived by replaying events. Instead of a balance column you overwrite, you keep the immutable history and compute the balance by folding over it. The database becomes a ledger, not a snapshot.

What it buys — and what it costs

The benefits are genuinely powerful for the right domain. Complete audit trail: every state change is recorded with its cause, permanently — regulators and forensic investigations love this, and for financial, legal, and compliance domains it’s often the point. Time travel: reconstruct state as of any past moment by replaying to that point — invaluable for debugging (“what did the system believe at 14:32?”) and retroactive analysis. New read models for free: replay the same event log through different projections to build new views without migrating data. But the costs are steep and routinely underestimated. Eventual consistency and the mental shift from “read the value” to “replay the history”; schema evolution pain (events are immutable and forever, so a v1 event format lives in your log permanently — versioning events is a permanent discipline); query complexity (answering “what’s the current balance?” means replaying or maintaining projections — hence CQRS almost always tags along); and snapshotting to avoid replaying millions of events on every read.

When it’s worth it (usually: not)

Event sourcing shines in domains where the history is the value: finance, ledgers, order lifecycles, anything audited or requiring temporal queries. It’s frequently paired with CQRS (separate write model of events, read models of projections) and event-driven architecture. For most CRUD applications, though, it’s over-engineering — a simple mutable table answers “what’s the current value?” directly, and the audit needs are met by a changelog table at a fraction of the complexity. The honest default: reach for event sourcing when the domain genuinely demands full history, not because it sounds sophisticated.

What people get wrong

• Event sourcing a CRUD app — adopting replay complexity and eventual consistency where a table and a changelog sufficed.
• Ignoring event schema evolution — immutable events mean old formats live forever; version them from day one.
• No snapshotting strategy — replaying an ever-growing log on every read eventually crawls.

Primary source: Martin Fowler — Event Sourcing