Event sourcing answers a narrow question elegantly — how do we remember everything that happened, in order, and rebuild state from it? — and fails expensively when applied to problems it was not designed for. The 2026 consensus has hardened around a clear fit test rather than architectural enthusiasm.

Where the payoff is real

Domains with regulatory audit requirements, complex state machines, or genuine need for time-travel benefit substantially. When every state change must be reconstructable, an append-only event log is the natural model rather than an imposed one.

The costs teams underestimate

Projections, schema evolution of events, snapshotting, and the learning curve for the whole team are recurring costs. Systems that do not need the audit trail pay these costs for a capability nobody uses.

Development illustration
Illustration: Development — photo via Unsplash

Start without it

Model the domain with conventional persistence first. If audit and temporal queries become pressing requirements, migration to event sourcing is feasible; adopting it speculatively and discovering it is wrong is far more expensive.

Where it genuinely fits

The pattern earns its complexity when the history is the product: financial transactions, audit trails, IoT sequences, collaboration timelines, and domains where replaying events produces derived state that must be recomputable. If you regularly ask "what exactly happened and when," events are the answer, and the append-only log gives you audit, temporal queries and state reconstruction in one mechanism. Domains with these properties rarely regret the investment.

Where it hurts

The warning signs: simple CRUD with no interest in history, teams without event-modeling experience, and queries that constantly need projections nobody has designed yet. The ongoing costs are real — schema evolution of stored events, projection rebuilds that take hours, and a debugging model that is unfamiliar to new engineers. The pragmatic middle many teams landed on in 2026: event sourcing for the specific aggregates that need it, conventional storage for everything else, and clear boundaries between the two.

Development illustration
Illustration: Development — photo via Unsplash

Key takeaways

  • Use it when history is the product — audit, replay, temporal queries.
  • CRUD domains and unprovisioned teams are the warning signs.
  • Boundary the pattern per aggregate; do not source the whole system.

Final thoughts

Event sourcing in 2026 is a specialized tool with a well-mapped fit test, and the teams happiest with it applied the pattern surgically to domains where remembering everything genuinely pays.

Sources & further reading