A team proposes event sourcing for a customer preferences service. What questions do you ask?
Show the full answer Hide the answer
What the interviewer is testing
Whether you can identify when a powerful pattern is being applied to a problem that does not have its requirements.
The questions
What requires a full history of changes? Event sourcing's core benefit is a complete, replayable record of everything that happened. If the requirement is "we might want an audit trail", a change log table gives that at a fraction of the complexity.
Who needs temporal reconstruction? Being able to ask "what were this customer's preferences on 3 March" is genuinely valuable in some domains and rarely needed for preferences.
Are there multiple read models? If several consumers need differently shaped projections of the same changes, event sourcing composes well. One read model does not justify it.
Does the domain naturally produce events? Some do — a ledger, a workflow, a claim. Preferences are typically last-value-wins state, and forcing events onto them is awkward.
Who will operate it? Projection rebuilds, event versioning across schema changes, eventual consistency between the write model and read models, and the fact that a defect in a projection means a rebuild rather than an update.
How does erasure work? Preferences are personal data, and an immutable event store meets the right to erasure only with crypto-shredding designed in from the start. This is a real constraint and is usually discovered late.
The likely conclusion
For a preferences service, a table with a change log and an updated-at timestamp meets the actual requirements. Event sourcing here buys optionality that will not be exercised, at a permanent operational cost paid by whoever is on call.
What a strong answer adds
Naming where it genuinely fits — ledgers, trading, insurance claims, anything with regulatory reconstruction requirements or complex temporal logic — so the pushback reads as judgement rather than conservatism.
Common weak answers
Approving because the pattern is sound. Rejecting event sourcing categorically.