Is event sourcing worth it?

Of all the patterns that arrive in our review queue, event sourcing has the widest gap between the elegance of its pitch and the mood of its operators two years in. This briefing is our standing answer to the title question, which clients ask us roughly quarterly, and which deserves better than the usual volley of conference talks in each direction.

what is actually being proposed?

Definitions first, because the pattern suffers from bundling. Event sourcing, strictly: the system's source of truth is an append-only log of domain events, and current state is a derivation, rebuilt or maintained by replaying them. It is routinely bundled with CQRS, with event-driven integration and with streaming infrastructure, and most of the regret in our files traces to adopting the bundle when the argument justified one item. A team can have events on a bus without event sourcing. A team can have read models without either. Unbundle before deciding.

what would have to be true for it to pay?

The strict pattern buys three things that nothing else buys as well: a perfect audit of how state came to be, the ability to answer questions retroactively (define a new projection, replay history, and you have data since forever), and temporal correctness under dispute, what did we believe on March 3rd. Domains where those are load-bearing, ledgers, trading, claims, anywhere a regulator or an adversary interrogates the past, get value no CRUD schema matches. We have signed recommendations for it there, without hedging.

The price list, equally concrete. Schema evolution becomes a permanent discipline: events written in 2026 will be replayed by code in 2031, so every event is a contract with your own future, versioned forever. Projections and replays become operational surface: rebuild time grows with history, and the estate acquires the storage-and-snapshot arithmetic the pitch deck skipped. Deletion becomes architecture: an immutable log meets a privacy regime's erasure demand only through encryption-and-key-destruction schemes designed at write time, which is what a system should forget arriving with subpoena force. And the everyday tax: every engineer who joins must learn to think in events, and the hiring pool that already does is small.

where does the regret concentrate?

Our files are consistent. Regret concentrates where event sourcing was adopted domain-wide, as an identity rather than a tool: fifty aggregates event-sourced because three needed it, the checkout flow paying the audit tax of the ledger, the team rebuilding projections at 2 a.m. for a feature whose product manager wanted a list sorted differently. The pattern is strong medicine, and the dose was the error. We have never once been called into an estate that regretted event-sourcing its actual ledger. We have never left one that was happy about event-sourcing its user profiles.

what do we recommend?

The boring, effective middle. Identify the aggregates where the past is genuinely load-bearing, usually one to three per company, and event-source those, with the schema-evolution and erasure disciplines funded from day one. Everywhere else, keep state conventional and, if integration needs it, publish events as notifications rather than truth, which captures most of the connective value at none of the replay cost. The two designs coexist without friction; the boundary between them is an ordinary interface.

Is it worth it? For your ledger, probably, and the conditions are checkable: name the questions only replay can answer, and if the business signs three of them, sign the pattern. For your estate, almost certainly not, and the teams happiest with event sourcing in our experience are precisely the ones who could tell you, aggregate by aggregate, why each one is or is not on the log. The pattern rewards discrimination. The identity version bills for it.