Event Sourcing
Storing every state change as an immutable event instead of just the current state. You can rebuild any past state by replaying events.
What is Event Sourcing?
In short
Event sourcing is a way of storing data where you save every change to your application's state as a sequence of immutable events, instead of overwriting a single current value. The current state is derived by replaying those events in order, so you keep a complete, auditable history of how the system reached any point in time.
What it actually is
In a normal database you keep one row per thing and update it in place. A bank balance starts at 100, you spend 30, and the row now reads 70. The 100 and the 30 are gone. You know the answer but not the story.
Event sourcing flips this. You never overwrite. Instead you append facts about what happened: AccountOpened with 100, MoneyWithdrawn of 30. The balance of 70 is not stored anywhere directly. It is a calculation you run by replaying the events from the beginning.
Each event is immutable and named in the past tense because it describes something that already occurred and can never be untrue. The ordered list of all events is your single source of truth. Everything else, including the current balance, is a view you can throw away and rebuild.
How it works under the hood
Events are written to an append-only log called the event store, usually grouped into streams. One stream per account, per order, or per shopping cart is common. Appending is a simple insert, which is fast and avoids the lock contention you get from updating hot rows.
To get current state you load the stream and fold the events into an in-memory object called an aggregate. Replaying thousands of events on every read would be slow, so systems take periodic snapshots. A snapshot stores the computed state at event number 5000, and you only replay events 5001 onward.
Reads almost never hit the raw event log. Instead a projector subscribes to the event stream and builds read-optimized tables, search indexes, or caches. This pairing with CQRS, where writes go to the event store and reads come from projections, is so common that the two patterns are usually discussed together.
Because the log is the truth, you can build a brand new projection at any time by replaying history. Want a report you never thought of at launch? Write a new projector, replay every event from day one, and the table fills itself.
When to use it and the trade-offs
Reach for event sourcing when history is part of the product. Accounting ledgers, order workflows, medical records, and anything needing a real audit trail benefit because the audit log is the data, not a side table that can drift out of sync.
The costs are real. Querying is harder since current state is not just sitting in a column. You need projections for every read shape, and those projections are eventually consistent, so a write may take a moment to show up in a query. Eventual consistency surprises teams used to reading their own writes immediately.
Schema change is the sharpest edge. Old events are permanent, so when an event shape changes you must keep handling the old version forever or run upversioning, where you transform old events into the new format as you read them. Deleting data for privacy laws like GDPR also fights the append-only model, usually solved with crypto-shredding where you throw away the encryption key.
If your domain is simple create-read-update-delete with no need for history, plain tables are cheaper and simpler. Do not adopt event sourcing for the resume. Adopt it when the business genuinely cares about the sequence of what happened.
Where it is used in production
Apache Kafka
Often used as the durable, ordered event log that backs event-sourced systems, with topics acting as append-only streams consumed by projectors.
EventStoreDB
A database built specifically for event sourcing, with native streams, optimistic concurrency, and built-in projections.
Walmart
Uses event-driven and event-sourced patterns in its order and inventory systems so every state change is captured and replayable.
AWS
Documents event sourcing as a core pattern, commonly implemented with DynamoDB streams or Kinesis feeding Lambda projectors.
Frequently asked questions
- Is event sourcing the same as CQRS?
- No. CQRS just means you separate the write model from the read model. Event sourcing is about how you store data, as a log of events. They pair so well that people use them together, but you can do CQRS with normal tables and you can event source without splitting reads and writes.
- How is it different from a normal audit log?
- An audit log is usually a secondary record you write alongside your real state, and it can drift or be incomplete. In event sourcing the events are the primary and only source of truth. Current state is derived from them, so the history can never disagree with reality.
- Does replaying all events make reads slow?
- It would, so you rarely replay from scratch. Snapshots store computed state at intervals so you only replay recent events, and projections maintain ready-to-query tables that reads hit instead of the raw log.
- How do you delete user data under GDPR if events are immutable?
- The common technique is crypto-shredding. You encrypt personal data inside events with a per-user key, and to forget a user you destroy their key. The events remain but their sensitive contents become unreadable forever.
- What happens when I need to change an event's shape?
- Old events are permanent, so you version your events. Either keep handlers for every old version or run upcasting, where you transform old events into the latest shape as they are read. You never edit history in place.
Learn Event Sourcing hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Event Sourcing as part of a larger topic.
See also
Related glossary terms you might want to look up next.
CQRS
Command Query Responsibility Segregation: using different models for reading and writing data. Reads and writes have different performance needs, so separate them.
Kafka
A distributed event streaming platform that handles millions of events per second. Used by LinkedIn, Netflix, and Uber for real-time data pipelines.
Saga Pattern
A way to manage distributed transactions across microservices using a sequence of local transactions with compensating actions for rollback.
CAP Theorem
In a distributed system, you can only guarantee two of three: Consistency, Availability, and Partition tolerance. You must choose your trade-off.
Consensus
The process of getting multiple nodes in a distributed system to agree on a single value. The foundation of distributed databases and coordination services.
Paxos
A family of protocols for solving consensus in unreliable networks. Famously difficult to understand but mathematically proven correct.