Sign in to keep reading
“Event Sourcing and CQRS” is free with an account. Your progress and bookmarks follow you across devices.
Sign in to continueNEW: ML Mock & Coaching with a 20+ year experience coach. Save $20 on sessions for Premium.ML Mock & Coaching now available
NEW: ML Mock & Coaching with a 20+ year experience coach. Save $20 on sessions for Premium.ML Mock & Coaching now available
Store state as an immutable sequence of events and separate read and write models for audit trails, temporal queries, and optimized access patterns.
“Event Sourcing and CQRS” is free with an account. Your progress and bookmarks follow you across devices.
Sign in to continueIn the Payment System question, you need to know exactly how an account reached its current balance. In Google Calendar, you want to undo a meeting change and see what the schedule looked like yesterday. In Ads Click Aggregator, every single click matters for billing, and losing one is losing money.
Traditional CRUD databases cannot answer these questions well. When you UPDATE balance = 500, the previous value is gone. There is no record of how it became 500, no way to rewind, no audit trail. For systems where history, correctness, and replayability matter, you need a fundamentally different approach.
That is what event sourcing and CQRS provide. They are separate ideas that pair naturally together, and they show up in many showoffer questions.
In a traditional CRUD system, your database stores the current state. An UPDATE overwrites whatever was there before. This works fine for many applications, but it has a fundamental limitation: it destroys information.
Event sourcing flips this model. Instead of storing current state, you store the sequence of events that produced it. The current state is derived by replaying all events from the beginning.
For a bank account, instead of storing balance: 500, you store:
The current balance (500) is computed by replaying these events in order. Every event is immutable -- you never update or delete an event. To "undo" something, you append a compensating event (for example, RefundIssued).
See it in practice: The Payment System question is the canonical event sourcing application -- every financial transaction is recorded as an immutable event in an append-only ledger. The Leaderboard question benefits from event sourcing because score changes can be replayed to rebuild rankings after rule changes.
The core of event sourcing is an append-only event log. Each entry records what happened, when it happened, and to which entity. Events are never modified or deleted.
Every event carries a few key properties:
To get the current state of an entity, you load all its events and replay them in order. This gives you three superpowers that CRUD cannot match:
Complete audit trail. Every change is recorded with who, what, and when. This is a legal requirement for financial systems and invaluable for debugging production issues.
Temporal queries. Need to know the state at 3pm yesterday? Replay events up to that timestamp. Need to know when a specific change happened? Search the event log.
Event replay. Ship new business logic? Replay old events through it. Need to backfill a new analytics dashboard? Replay the entire event history. Need to debug a production issue? Replay the exact sequence of events that led to the bug.
See it in practice: In Bookstore, event sourcing provides an audit trail for inventory changes -- every stock adjustment, purchase, and return is traceable. In Online Chess, the full move history is an event log that enables replay, analysis, and dispute resolution.