How Event Sourcing Works
AdvancedEvent sourcing stores the full history of what happened as an immutable, append-only sequence of events, rather than just the current state. Instead of updating a row to balance = 90, you append events like Deposited(100) and Withdrew(10); current state is derived by replaying them. This gives a perfect audit trail, the ability to reconstruct past states, and a natural fit with CQRS — at the cost of more complexity and eventual consistency.
Think of a bank statement versus a balance
A single balance figure tells you where you are but nothing about how you got there. A bank statement lists every deposit and withdrawal — the events. From the statement you can always recompute the balance, see the state at any past date, and audit every change. Event sourcing chooses to keep the statement as the source of truth, deriving the balance whenever needed, rather than storing only the balance and losing the history.
Step by Step
Key Concepts
Event Store
An append-only log of immutable events, the source of truth. Events are only ever added, never modified, which is what preserves the full history.
Replay
Reconstructing current (or historical) state by applying a sequence of events in order. Because state is derived, you can rebuild it at any point in time.
Snapshot
A saved copy of an entity state at a point in time, used to avoid replaying its entire event history. Rebuilding loads the snapshot then replays only newer events.
Projection
A read model built by processing the event stream. New projections can be created by replaying existing events, making it easy to add new views of the same data.
Key Facts
- The event log is the source of truth; current state is a derived, disposable view you can always recompute.
- Event sourcing gives a complete audit trail and time-travel debugging for free — huge for finance, compliance, and diagnosing "how did we get here?".
- The cost is complexity: schema/versioning of events, eventual consistency of projections, and the need for snapshots — so use it where history and auditability truly matter.
Real-World Applications
Financial ledgers and audit
Banking and accounting systems store every transaction as an event, giving an immutable audit trail and the ability to reconstruct any account state at any past moment — a natural fit for regulatory requirements.
Order lifecycle tracking
An order stored as a stream of events (placed, paid, shipped, delivered) makes its full history queryable, supports new dashboards by adding projections, and never loses the intermediate states a single status column would overwrite.
Frequently Asked Questions
What is event sourcing?
Event sourcing is a pattern where you store state as an immutable, append-only sequence of events describing what happened, rather than storing only the current state. Instead of updating a balance field, you append events like Deposited and Withdrew, and derive the current balance by replaying them. The event log becomes the single source of truth.
How do you get the current state in event sourcing?
You reconstruct it by loading an entity events in order and applying each one to build up the current state. Because replaying a long history is slow, systems periodically save snapshots of the state, so rebuilding means loading the latest snapshot and replaying only the events that occurred after it.
What are the benefits of event sourcing?
You get a complete, immutable audit trail of every change for free, the ability to reconstruct the state at any past point in time (time-travel debugging), and easy creation of new read models by replaying events into new projections. It also pairs well with CQRS. These benefits are especially valuable in finance, compliance, and complex domains.
What are the downsides of event sourcing?
It adds significant complexity: you must design and version events carefully, handle eventual consistency of projections, and manage snapshots for performance. Querying current state requires replay or projections rather than a simple SELECT. Because of this, event sourcing is best reserved for domains where auditability and full history genuinely justify the overhead, not for simple CRUD applications.