We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Distributed Systems Core
Storing every state change as an immutable event instead of just the current state. You can rebuild any past state by replaying events.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Event Sourcing across a run of lessons, not one page. These 4 alone are about 113 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
Store events instead of state, rebuild any point in time from the log of what happened.
Build systems where everything reacts to events, the architecture powering Netflix, Uber, and LinkedIn at massive scale.
Capture every database change as a stream of events, the backbone of modern data pipelines.
The critical distinction between when an event occurred and when the system processes it.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Event Sourcingpay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
When a network failure splits a distributed data store, each node must either refuse requests to stay consistent or keep answering with possibly stale data. It cannot guarantee both during the partition.
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.
This page explains the idea. The "Event Sourcing" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Event Sourcing lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Event Sourcing in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
