Event sourcing stores every change to a piece of data as an immutable event, rather than overwriting a row with its latest value. The current state of anything — an account balance, an order, a user profile — is not stored directly. It is derived by replaying every event that ever happened to it, in order. The event log is the source of truth; everything else is a rebuildable view on top of it.
What changed in 2026
- Managed event stores became a real category, not a DIY project. More teams now run on hosted event-store or log platforms instead of hand-rolling append-only tables and replay logic themselves.
- Schema evolution tooling caught up. Versioned event schemas and upcasting — transforming old event shapes into new ones during replay — are now standard practice, closing one of the pattern's oldest pain points.
- Event sourcing narrowed to where it actually pays off. The 2026 default is to apply it to specific aggregates that need history or replay, such as orders, ledgers, and workflow state, not to an entire system by default.
How event sourcing works
Every change is appended as an event, never updated or deleted. "OrderPlaced," "ItemAdded," "OrderShipped" — each is a fact about something that happened, timestamped and immutable. Current state is a projection: to know an order's current status, you replay its events in order and fold them into a final value. That projection can be cached, but the log stays authoritative. Multiple projections can read the same log — a shipping view, a billing view, and an analytics view can each build a different shape from the same underlying events, which is the natural pairing with CQRS.
Event sourcing vs traditional state storage
| Approach |
What is stored |
History |
Rebuild cost |
Best for |
| Traditional row |
Current value only, overwritten on update |
None, unless logged separately |
None, the value is already current |
Simple entities with no audit need |
| Event sourcing |
Every event, current value derived |
Full, by design |
Replay cost, mitigated by snapshots |
Ledgers, orders, workflows, anything audited |
| Event sourcing + snapshots |
Events plus periodic state checkpoints |
Full |
Low, replay from latest snapshot forward |
High-volume entities with long histories |
Snapshotting: solving the replay cost
Replaying ten events to get current state is free. Replaying two million events on every read is not. Snapshotting fixes this: periodically save the fully computed state as of a given event, then future reads replay only the events since that snapshot instead of from the beginning.
This is the detail that makes event sourcing viable at scale. Without it, the pattern degrades as history grows, which is exactly the kind of operational surprise that shows up months after launch, not in the prototype.
When event sourcing is worth it
Reach for event sourcing when you need a genuine audit trail — financial ledgers, inventory movements, regulated workflows where "what happened and when" is a requirement, not a nice-to-have; when you need to rebuild past state for debugging, analytics, or compliance, not just see the current value; or when multiple read models need to derive from the same source of truth, which pairs naturally with CQRS.
Skip it for entities that only ever need a current value, such as a display name, a feature flag, or most configuration data. The append-only log, schema versioning, and replay tooling are ongoing costs that do not pay for themselves there.
Common mistakes
Event-sourcing the entire system by default. Apply it aggregate by aggregate, only where history and replay have real value. Mixing it with plain CRUD models elsewhere is normal and expected.
Treating events as mutable. Once appended, an event does not change. If the past was wrong, append a correcting event, never edit or delete history.
Skipping snapshots until performance breaks. Retrofitting snapshotting after an event stream has grown huge is far more painful than building it in from the start.
No schema versioning plan. Event shapes change over years, not months. Without a versioning and upcasting strategy, old events become unreadable by new code.
FAQ
Is event sourcing the same as event-driven architecture?
No. Event-driven architecture is about services communicating via events. Event sourcing is about how one service stores its own state. They pair well but are separate decisions.
Does event sourcing require CQRS?
No, but they are frequently used together because a projection built from an event log is naturally a read-optimized model, which is the core idea behind CQRS.
How do you delete data in an event-sourced system?
You append a compensating or tombstone event rather than deleting history, then handle hard-deletion requirements, such as privacy regulations, at the projection or storage layer, often by encrypting and discarding keys rather than rewriting history.
What is the biggest operational cost of event sourcing?
Schema evolution over time and the discipline required to keep replay working correctly as event shapes change. Snapshotting solves performance; it does not solve versioning.
Where to go next