Event sourcing stores every change to your data as an immutable event, OrderPlaced, OrderShipped, OrderCancelled, instead of overwriting a row's current state. The current state of any object is derived by replaying its events in order, not stored directly. This gives you a complete audit trail for free, the ability to rebuild any past state, and a natural fit for systems where what happened and when matters as much as what is true now, but it adds real complexity that a simple CRUD table does not have.
The core idea
Instead of an orders table with a status column that gets overwritten, you have an append-only events table: every state change is a new row, never updated or deleted. To get the current state of an order, you load all its events and replay them through a function that applies each one to a running state object. That replay function is the only place business logic about what an event does to the state lives.
What changed in 2026
- Postgres-based event stores became the default starting point, over dedicated products like EventStoreDB, for teams that did not want another piece of infrastructure to operate.
- Schema evolution tooling matured — upcasting old event shapes to new ones at read time is now a well-documented pattern instead of a bespoke migration script every team invents separately.
- Snapshotting became standard practice past a few hundred events per aggregate, storing periodic state snapshots so replay does not mean reading an ever-growing event log from the beginning every time.
- Event sourcing narrowed to where it actually pays off — financial ledgers, order and fulfillment pipelines, and anything with compliance-driven audit requirements, rather than being proposed for every domain.
How it works
| Step |
What happens |
| 1. Command arrives |
A command like PlaceOrder hits the write model |
| 2. Business logic validates it |
Check invariants against current state, rebuilt from past events |
| 3. Event is appended |
OrderPlaced is written to the append-only event store, never mutated |
| 4. State is derived |
Current state equals the replay of all events for that aggregate, in order |
| 5. Projections update |
Read-optimized views are rebuilt from the same event stream, often asynchronously |
Projections are usually where CQRS enters the picture — see CQRS explained in 2026 for how the read side is typically structured separately from this write path.
Common mistakes
Applying event sourcing to every entity in a system. Most data is simpler as current-state rows; reserve event sourcing for aggregates where history and auditability are genuinely valuable, like orders, ledgers, or contracts.
Never snapshotting. Replaying thousands of events to compute current state on every read is a self-inflicted performance problem — snapshot periodically and replay only the events since the last snapshot.
Treating events as mutable. An event that already happened cannot be edited to fix a bug — you append a compensating event instead, the same way accounting reverses an entry rather than erasing it.
No plan for schema evolution. Event shapes change over years of production use; without an upcasting strategy, old events become unreadable by new code the first time you rename a field.
FAQ
Is event sourcing the same as CQRS?
No, though they are often paired. Event sourcing is about how you store state, as events; CQRS is about separating the read and write models. You can do either without the other.
Does event sourcing require a special database?
No — many production systems implement it on plain Postgres with an append-only table and a sequence number per aggregate; dedicated event stores add features but are not required to start.
How do you handle bugs in past events?
You do not edit history — you append a new compensating event that corrects the derived state going forward, preserving the audit trail.
When should I avoid event sourcing?
When the domain has no real need for history or audit trails and the team has no existing experience with the pattern — the operational and cognitive overhead is real and not free.
Where to go next
Read CQRS explained in 2026 for the read-model half of this architecture, and design patterns explained in 2026 plus the factory pattern explained in 2026 for the object-construction patterns commonly used to rebuild aggregates from their event history.