DataExpert

What do you gain and lose by storing events instead of state?

“A bank-ledger team stores `AccountOpened +100`, `PaymentMade −20`, `RefundReceived +20` and replays them for the balance. What does this buy them, what does it cost, and where would you not do it?”

What this tests

  • Audit, temporal queries and replay as the real benefits
  • Snapshots, event versioning and upcasting as the operational cost
  • Deletion / GDPR and query difficulty as the hard problems
  • Choosing it per aggregate, not per system

Answers by level

Read the beginner answer first and notice what is missing.

Gain: the event log is the truth, so you get a complete audit trail, the ability to answer "what was the balance on 3 March", and the ability to fix a bug in a projection and replay history into a corrected read model. For a ledger, where the sequence of facts is the domain, that is exactly right.

Cost: current state is derived, so every read either replays events or hits a projection; you need snapshots (every N events) to bound replay time for long-lived aggregates. Events are immutable, so changing what PaymentMade means requires versioning and upcasting old events on read. Ad-hoc queries ("all accounts with balance < 0") need projections; you cannot SELECT the log. And deletion is structurally hard: GDPR erasure against an immutable log requires crypto-shredding (per-subject keys you can destroy) or tombstoning that projections respect — see Event Sourcing.

Green flags · Red flags

Strong green flag · Says replay must be deterministic and explains the concurrency control on the stream, unprompted.
Green flags
  • Names audit, temporal queries and replay as the specific benefits
  • Snapshots, versioning/upcasting and projections as concrete costs
  • Optimistic concurrency with expected_version
  • Has an answer for GDPR erasure (crypto-shredding)
  • Applies it per aggregate; rejects it for CRUD entities
Red flags
  • "Event sourcing gives you an audit log for free, so use it everywhere."
  • Conflates event sourcing with publishing events to Kafka
  • No plan for schema change on old events
  • Treats deletion as "we just delete the events"

Follow-up questions

F1
An account has 2 M events. How do you read its balance in 10 ms?
F2
You rename a field in PaymentMade. What happens to the 50 M existing events?
F3
Two withdrawals race on the same account. How does the system prevent an overdraft?

Scenario

A fintech stores every account change as events and replays them for balances. Two years in, the biggest account has 40 M events, the balance endpoint p99 is 6 s, a regulator demanded erasure of a closed customer's data, and a developer changed the shape of PaymentMade and broke replay for 2019 events. Explain which decisions were sound and what should have been designed in from the start.

Learn this topic