Event Sourcing vs Traditional State

Event sourcing stores every state change as an immutable event. Traditional state management stores only the current state, overwriting previous values. This fundamental difference has far-reaching implications.

The Event Sourcing Model

Instead of updating a row when a user changes their address, event sourcing appends an "AddressChanged" event to the event store. The current state is derived by replaying all events for that entity from the beginning.

This gives you a complete audit trail, the ability to reconstruct state at any point in time, and a natural integration point for downstream systems that can subscribe to the event stream.

The Performance Challenge

Replaying hundreds of events per query is impractical. Event-sourced systems solve this with projections — materialized views built by processing the event stream into queryable tables. This is essentially CQRS: events are the write model, and projections are the read model.

Snapshots further optimize performance by periodically persisting the computed state, so replay starts from the snapshot rather than the beginning.

When Event Sourcing Is Overkill

For a blog, a todo app, or an admin dashboard, event sourcing adds enormous complexity with little benefit. The audit trail, temporal queries, and event replay capabilities are powerful but unnecessary for most applications.

When It Is Essential

In financial systems, event sourcing is natural — a ledger is already an event log. In regulatory environments, the audit trail is a compliance requirement. In complex domains, replaying events to debug production issues or build new analytics projections is invaluable.

Explore our event sourcing concept guide and system design interview guide. See pricing for practice problems.

The Bottom Line

Use traditional state management as the default. Adopt event sourcing when you need audit trails, temporal queries, or event replay — and are willing to invest in the infrastructure to support projections and snapshots.