Event Sourcing

1The core idea#

Normal systems keep the answer. Event sourcing keeps the questions. That is the whole flip.

• CRUD keeps the current value. Your bank row says balance = 420. Spend 50 and the system updates the row to 370. The old number is gone forever. As far as the database is concerned, it never existed.
• Event sourcing keeps the facts. You never store the balance. You store a list of things that happened: AccountOpened, Deposited 500, Withdrew 80, Withdrew 50. The balance is something you compute by replaying that list.
• State becomes a function of history. Replay the exact list on any machine and you get 500 - 80 - 50 = 370, every time.

The one line to anchor on:

• The log of events is the source of truth.
• Everything else, including the "current balance" on the screen, is a derived view you can throw away and rebuild.

Two properties fall out immediately, and interviewers love both:

• Nothing is ever lost. An update is just another event appended to the end. Ask "what was the balance on March 3rd at noon" and you replay events up to that timestamp. Try that with a plain UPDATE.
• Writes are append-only. You only ever add rows to the end of a log. No in-place mutation, no update lock on the hot row. The write is a single sequential insert, not a read-modify-write on a contended row.

The trade-off hits just as fast: reading the current state now costs you a replay. Section 2 deals with it.

2How it works#

Four moving parts, and the interview punishes you for blurring them: the command, the event, the event store, and the projection.

• Command. A request to change something: "transfer 50 dollars." A command can be rejected. The domain logic looks at current state, decides if it is valid, and emits events if so. TransferMoney is a command.
• Event. A fact in the past tense. It already happened, so it cannot be rejected or deleted. MoneyTransferred is an event.
• Event store. An append-only log, ordered per entity (an "aggregate" in DDD terms, like one bank account). Appending is the only write operation.
• Projection (read model). Consumes the event stream and builds whatever shape your reads need: a balance table, a search index, a cache. Many projections can feed off the same events, each tuned for a different query.

Why this pairs with CQRS.

• The separate write and read pipelines are exactly what CQRS (Command Query Responsibility Segregation) asks for.
• They are not the same thing, but they fit like a hand in a glove: CQRS says split your write model from your read model, event sourcing hands you a natural write model (the log) plus a natural way to feed any number of read models (projections off the stream).

The obvious problem: an account open for ten years has 40,000 events. You are not replaying all of them on every balance check. Two fixes:

• Snapshots. Every N events, write the computed state to the side. To get current state, load the latest snapshot and replay only the events after it. Replaying 50 events is cheap. Replaying 40,000 is not.
• Maintained projections. Keep the read model continuously up to date as events arrive, so a balance read is a normal indexed lookup. This is what most real systems do. The replay-from-scratch path is reserved for rebuilding a projection, not for serving live reads.

3A worked example with real numbers#

"Replay the log" stays abstract until you put a latency number on it. Say I am designing the balance service for a neobank with 10 million accounts.

The event stream for one account. Account acc_7781 has these events, each roughly 300 bytes on disk after serialization:

seq 1  AccountOpened          balance effect  +0
seq 2  Deposited      50000   (500.00)        +50000
seq 3  Withdrew        8000   ( 80.00)        -8000
seq 4  Withdrew        5000   ( 50.00)        -5000
current balance = 37000 cents = 370.00

• I store money in integer cents, never floats.
• 50000 - 8000 - 5000 = 37000, which is 370 dollars.
• Replaying 4 events takes microseconds.

Now scale it in time.

• This account is active for 10 years and averages 11 events a day (card swipes, interest postings, fees). That is roughly 40,000 events.
• Each replay reads 40,000 rows at 300 bytes each, so about 12 MB of I/O just to answer "what is the balance."
• At, say, 1,000 balance checks per second across hot accounts, naive replay is dead on arrival.

Fix it with a snapshot.

• I snapshot every 500 events. To read the balance I load snapshot number 80 (state after seq 40,000) and replay the 0 to 499 events since.
• Worst case replay is 499 events, about 150 KB, versus 12 MB. That is an 80x cut in read I/O, and it stays flat as history grows.
• The snapshot itself is one small row: {account, seq: 40000, balance: 37000}.

Fix it better with a maintained projection.

• I keep a balances table updated as each event lands: one indexed row per account.
• GET balance is a single primary-key lookup around 1 ms.
• The 40,000-event log sits untouched behind it, used only for audit and for rebuilding the projection if it ever gets corrupted.

Sizing the whole system.

• 10M accounts times 40,000 events times 300 bytes is about 120 TB of event log over a decade.
• That sounds scary until you remember it is append-only and cold: 99% of it is never read.
• The hot read path is the balances projection: 10M rows at maybe 80 bytes, under 1 GB, fits in memory on one box.
• The shape of the whole trade: a large cheap immutable log plus small hot derived views. Say those numbers in an interview and you stop sounding theoretical.

4Trade-offs#

This is where interviews are won or lost. Anyone can describe the pattern. You get hired for knowing what it costs.

The three things you actually give up:

• Query complexity. You cannot SELECT * FROM accounts WHERE balance > 1000 against a log. There are no rows with balances in it. Every query you want has to be served by a projection you built ahead of time. If a product manager asks for a new report next week, you may need a new projection and a full replay to populate it. Against the 120 TB log, that replay is a real job you have to plan, not a one-liner.
• Schema evolution of events. Events are immutable and they live forever. Ship OrderPlaced with price as an integer in cents, then three years later want it as a decimal with currency, and you cannot rewrite the old events. You carry versioned event types and "upcasters" that translate old shapes to new ones on read. This is the single most underestimated cost. Teams are usually fine for a year, then event versioning becomes a tax on every change.
• Eventual consistency. The projection lags the log, even if only by milliseconds. A user transfers money, the event is committed, but the balance view has not updated yet when they refresh. For a bank that is a lawsuit. For a social feed it is invisible. Know which side of that line your system sits on.

My honest take:

• Event sourcing is a specialist tool. Reach for it when history IS the product (ledgers, audit, compliance, anything where "why is it in this state" matters as much as the state).
• Do not reach for it because it sounds sophisticated.
• A plain CRUD table with a separate audit log solves 80 percent of what people think they need event sourcing for, at a fraction of the operational pain.

Saying no to your own pattern is the clearest senior signal in the room.

5Where it is used#

A few canonical fits, and what each one teaches:

• Financial ledgers. The canonical case. A ledger IS an event log by definition: you never edit a posted transaction, you post a correcting one. Accounting has worked this way for 500 years, so event sourcing is software catching up to double-entry bookkeeping.
• Order and fulfillment systems. An order moves through placed, paid, picked, shipped, delivered, returned. Each transition is a meaningful event that downstream systems (inventory, analytics, customer notifications) all want to react to. The event stream becomes the integration backbone.
• Version control. Git is event sourcing in disguise. Commits are immutable events, your working tree is a projection, and you can check out any point in history by replaying. If you understand Git, you already understand the pattern.
• Collaborative editing and distributed systems. When you merge changes from multiple sources or rebuild state on a new node, a stream of ordered events is far easier to reason about than reconciling two bags of mutable state.

The signal words that should make you reach for it:

• "audit," "regulatory," "undo/redo," "temporal query," or "replay for debugging."
• If the prompt is "design a URL shortener," event sourcing is the wrong answer and reaching for it shows poor judgment.

6Common pitfalls and gotchas#

The traps that separate someone who ran one of these from someone who read about it:

• Treating events as commands. New teams write events like UpdateBalance that carry the new value. That is a disguised CRUD update. A real event says what happened and why (MoneyWithdrawn 50), not what the row should become. Get this wrong and you lose the ability to re-derive state under new rules later.
• Fat events that leak current state. If your event stores the resulting balance (balance now 370) instead of the delta (withdrew 50), you have coupled the event forever to how you computed balance at that moment. Store the fact, derive the state. In the section 3 example, storing balance: 37000 inside the Withdrew event would bake a bug in old balance math permanently into history.
• No snapshot strategy. Day one, replays are instant because there are ten events. Eighteen months later a single aggregate has 100,000 events and your p99 latency quietly dies. Plan snapshots before you need them, not after the pager goes off.
• Ignoring idempotency on the read side. Projectors consume events, and in a distributed system they will occasionally see the same event twice (at-least-once delivery). If your projector does balance = balance + amount without tracking which events it already applied, a redelivery double-counts that 50 and corrupts the view. Track the last processed event position per projection and skip anything at or below it.
• Deleting data in a GDPR world. Immutable logs and "the user has a right to be forgotten" are in direct conflict. You cannot just delete events. The usual answer is crypto-shredding: encrypt personal data in events with a per-user key, then delete the key. The events remain but the PII is unrecoverable. Bring this up unprompted and interviewers notice.
• Rebuilding a projection takes hours. If a projection bug ships and you need to rebuild from a billion events, that replay can run for a long time. Teams that care keep projections rebuildable in parallel and partitioned by account, so a rebuild is minutes, not a weekend.

7How it shows up in interviews#

Interviewers probe event sourcing to see if you understand consistency, not just vocabulary. Here is what separates strong from weak, framed as the questions you will actually get.

The meta-move: mention CQRS and eventual consistency early, draw the split read/write diagram, and name snapshots and event versioning before you are asked. That tells the interviewer you have actually run one of these, not just read about it.

Next, try the System Design Question walkthrough on designing a payment ledger, where these trade-offs stop being theory and you have to pick a side.