What is Event Sourcing and How Does It Differ From Storing Current State?
Learn what event sourcing is, how it differs from storing current state, and how it pairs with CQRS.
Expected Interview Answer
Event sourcing stores every change to a system's data as an immutable, ordered sequence of events, and derives the current state by replaying those events, rather than storing and overwriting only the current state as a traditional table update would.
Instead of an Accounts table where a balance column is overwritten on every deposit or withdrawal, event sourcing persists an append-only log of events like AccountOpened, MoneyDeposited, and MoneyWithdrawn, and the current balance is computed by replaying all events for that account in order. This gives a complete audit trail for free, makes it possible to reconstruct the state at any past point in time, and pairs naturally with CQRS, since the event log serves as the write model while one or more projections (read models) are built by folding the events into whatever shape a query needs. The cost is added complexity: replaying long event streams needs snapshotting for performance, and schema changes to events require careful versioning since old events can never be rewritten.
- Complete, tamper-evident audit trail of every change, by construction
- Can reconstruct state as of any past point in time
- Pairs naturally with CQRS to build multiple read projections from one event log
- Enables replaying events to fix bugs or backfill new projections retroactively
AI Mentor Explanation
Traditional state storage is like a scoreboard that only shows the current total, overwriting the previous number after every run. Event sourcing is like keeping the full ball-by-ball commentary log — every run, wicket, and extra recorded in order — and computing the current total by replaying that entire log whenever needed. The commentary log never changes once written; new balls only append to it, and you can always reconstruct the score at any earlier over by replaying up to that point.
Event Sourcing: State Derived by Replaying an Event Log
Event Store (append-only)
- AccountOpened
- MoneyDeposited(+200)
- MoneyWithdrawn(-50)
Replay / Fold
- sum all events in order
Derived Current State
- balance = 150
Step-by-Step Explanation
Step 1
Append an event
Every state change is recorded as a new immutable event appended to that entity's event log, never overwritten.
Step 2
Persist events in order
The event store keeps events ordered per entity, forming the full history of everything that happened.
Step 3
Replay to derive state
Current state is computed by folding/replaying all events for an entity from the beginning (or from a snapshot).
Step 4
Optionally snapshot for performance
Periodically save a computed state snapshot so replay only needs events after that point, not the entire history.
What Interviewer Expects
- Clear contrast between storing current state vs storing an append-only event log
- Understanding that current state is derived by replaying/folding events
- Awareness of the audit-trail and point-in-time reconstruction benefits
- Knowledge of the trade-offs: replay cost, snapshotting, and event schema versioning
Common Mistakes
- Confusing event sourcing with simply logging changes for debugging purposes
- Forgetting that events are immutable and never edited or deleted after being written
- Not mentioning the need for snapshots to keep long-lived entities performant
- Assuming event sourcing always requires CQRS, when they are complementary but separate patterns
Best Answer (HR Friendly)
“Instead of storing just the current value and overwriting it every time something changes, event sourcing stores every change as its own permanent event, in order, and figures out the current state by replaying all of them. It gives you a full audit trail and the ability to see exactly how the data got to where it is at any point in time, at the cost of more complexity when replaying long histories or changing the event format.”
Code Example
-- Traditional: current state overwritten in place
UPDATE Accounts SET balance = balance + 200 WHERE account_id = 1;
UPDATE Accounts SET balance = balance - 50 WHERE account_id = 1;
-- history of how the balance got here is lost
-- Event sourcing: append-only, nothing is ever overwritten
CREATE TABLE AccountEvents (
event_id INT PRIMARY KEY,
account_id INT NOT NULL,
event_type VARCHAR(50) NOT NULL,
amount DECIMAL(10,2),
occurred_at TIMESTAMP NOT NULL
);
INSERT INTO AccountEvents (event_id, account_id, event_type, amount, occurred_at)
VALUES (1, 1, 'AccountOpened', 0, '2026-01-01 09:00:00');
INSERT INTO AccountEvents (event_id, account_id, event_type, amount, occurred_at)
VALUES (2, 1, 'MoneyDeposited', 200, '2026-02-01 10:00:00');
INSERT INTO AccountEvents (event_id, account_id, event_type, amount, occurred_at)
VALUES (3, 1, 'MoneyWithdrawn', -50, '2026-03-01 11:00:00');
-- Current balance is derived by replaying (summing) all events:
SELECT SUM(amount) AS balance FROM AccountEvents WHERE account_id = 1;Follow-up Questions
- How does event sourcing pair with CQRS in practice?
- What is a snapshot and why is it needed for long event streams?
- How do you handle changing the shape of an event type after events already exist?
- What happens if you need to reconstruct state as of a specific past date?
MCQ Practice
1. In event sourcing, how is the current state of an entity obtained?
Event sourcing derives current state by replaying the immutable, ordered sequence of events recorded for that entity.
2. What technique is commonly used to avoid replaying an entire long event history every time?
A snapshot stores the computed state at a point in time so replay only needs to process events after that snapshot.
3. What is a key benefit event sourcing provides "for free"?
Because every change is recorded as a permanent event, the full history of how data reached its current state is inherently preserved.
Flash Cards
What is event sourcing? — Storing every state change as an immutable, ordered event and deriving current state by replaying them.
How does it differ from storing current state? — Traditional storage overwrites a value; event sourcing appends new events and never overwrites history.
Why use a snapshot in event sourcing? — To avoid replaying an entity's entire event history by starting replay from a saved point-in-time state.
How does event sourcing relate to CQRS? — The event log serves as the write model, while one or more read projections are built by folding the events.