Interview framing
The interviewer asks you to compare event sourcing (store every state-changing event) with traditional state-based storage (current state only). They want criteria for when the complexity is worth it, especially for financial systems, audit trails, and time travel.
Background from first principles
Most applications store rows that mean "what is true now."
accounts(account_id, balance, updated_at)
An update sets balance = 120. The previous balance is gone unless you built separate audit tables.
That model is simple and fast for "show me the account." It fails a different question: "What was the balance last Tuesday before the adjustment, and which operations produced it?"
Event sourcing answers by storing facts about what happened, not only the latest summary.
Events: FundsDeposited(+50), FundsWithdrawn(-20), Adjustment(+5) Current balance = fold(events)
You need this distinction before arguing tools. Event sourcing is not "we use Kafka." Kafka can carry messages for many architectures. Event sourcing is a persistence model: the append-only event log is the source of truth for an aggregate, and current state is derived.
Full problem statement
Contrast event-sourced vs state-based designs for a mid-size transactional domain (orders or ledger). Cover:
- How to derive current state from events.
- Audit and time-travel benefits.
- Operational costs: replay, event schema evolution, storage growth.
- Consistency and idempotency of appends.
- Consumer rebuild lag for projections.
- A recommendation framework for when event sourcing is worth it.
What "good" looks like
You start with a support or audit question that current-state rows cannot answer. You define both models. You show a small ledger example. You introduce projections/read models and snapshots. You discuss compensating events instead of rewriting history. You give clear "when not" criteria. You handle GDPR as a thoughtful follow-up, not a shrug.
Clarifying questions
- Do regulators or finance require reconstructable history?
- Is current-state read latency critical for user-facing paths?
- How many event types evolve per year?
- Is the team ready to own replay tooling and versioned events?
- Do we need multiple read models from one fact stream?
Scale prompts
- Estimate events per account per year and storage vs overwrite-in-place rows.
- Replay time without snapshots for hot aggregates.
- Projection lag SLOs for user-facing reads.
Out of scope
- Turning every CRUD entity into events "for purity."
- Equating any message bus with event sourcing.
- Designing a global social graph event store unless the domain needs it.
Expanded domain story
Imagine a payments company. Accounts hold balances. Ops adjusts fees. Support investigates disputes. Auditors ask for reconstructable histories. Product wants a mobile balance that feels instant.
If you only store current balance, dispute investigations become archaeology across incomplete logs. If you event-source every profile font-color preference, you drown in ceremony.
Your interview answer must separate aggregates that need forensic history (ledger, reservations) from entities that need boring CRUD (display preferences).
Constraints to assume if not given
- Mid-size transactional domain, not a global social graph.
- Read latency for current balance matters for mobile.
- Some regulatory reconstructability is likely for money movement.
- Team has not operated an event store before; mention ramp cost.
What to write on the board early
1. Questions only events can answer. 2. Questions current state answers fine. 3. Recommendation per aggregate type, not one hammer for the whole company.
Background concepts the interviewer expects you to teach
Before naming patterns, explain:
1. Current state rows answer "what is true now?" 2. Event logs answer "what happened, in order?" 3. Derived read models answer "how do we show this quickly?"
Many candidates jump to Kafka. Strong candidates explain that the source of truth choice drives everything else: auditing, GDPR tension, replay tooling, and team complexity.
Full prompt restatement you can use
"We need to choose persistence for money movement and related workflows. Compare storing only current state versus storing every state change as events. Recommend when the complexity of event sourcing is justified, and explain projections, snapshots, corrections, and erasure pressures."
Good vs weak answers
Weak: "Event sourcing is always better for microservices."
Good: "Event sourcing pays for reconstructable history on ledger aggregates. CRUD remains right for simple profile state. Here is how projections keep reads fast, and here is how we correct errors without rewriting history."
Estimation prompts to volunteer
- Events per aggregate per year.
- Replay time with and without snapshots.
- Projection lag SLO for mobile balance reads.
- Storage growth vs operational benefit for audit.
Explicit out of scope
- Rewriting the entire company data model in one quarter.
- Exactly-once claims without idempotency design.
- Using the analytics lake as the only operational event store without durability and ordering guarantees per aggregate.