Data Engineering
Event sourcing: multiple-choice review
Crux Multiple-choice synthesis across event sourcing — log as source of truth, projections and CQRS, replay, snapshots, event versioning, and GDPR on an immutable log.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a decision you make designing or operating an event-sourced system — not a definition to recite, but a tradeoff to weigh when the log is the truth and everything else is derived.
Goal
Confirm you can connect the append-only log, projections, replay, snapshots, versioning, and GDPR — the synthesis the lesson built toward, at the depth where the decisions actually bite.
Quiz
Completed
A teammate argues 'we already publish domain events to Kafka after every DB write, so we are event-sourced.' Why is that probably false?
Heads-up Emitting events is necessary but not sufficient. The defining property is that the log is authoritative and state is derived from it, not that events are published as a side-channel after a database already holds the real truth.
Heads-up Kafka can serve as an event store with care (infinite retention, no compaction). The flaw here is the dual-write pattern where the DB holds truth, not Kafka itself.
Heads-up Partitioning is an ordering and throughput concern, unrelated to whether the log is the source of truth. The real issue is that a committed row, not the log, is authoritative.
Quiz
Completed
Why are projections (read models) safe to treat as disposable, and what does that buy you operationally?
Heads-up Disposability comes from being re-derivable by replay, not from backups. A backup restores an old shape; replay can build entirely new shapes the backup never had.
Heads-up Projections store derived state, never the authoritative events. The events live in the append-only store; the projection is a throwaway materialization of them.
Heads-up CQRS does the opposite — it lets you freely add, drop, and rebuild read models precisely because they are derived and disposable.
Quiz
Completed
A user clicks Save, you append the event, then redirect to a list rendered from the projection — and their change is not there. What is the root cause and the right fix?
Heads-up Forcing the projection to update synchronously with every append throws away the decoupling and scalability CQRS exists for, and the event was not lost — it just has not been projected yet.
Heads-up Idempotency is about safe redelivery of the same event, not about a missing event. The change is absent because the projection simply has not caught up — replay lag, not a duplicate.
Heads-up At-most-once trades duplicate risk for lost-event risk, which is worse here. The append likely succeeded; the read model just trails it by some lag.
Quiz
Completed
Loading one aggregate folds 4 million events and is too slow. You add snapshots. What is the one failure mode a senior guards against?
Heads-up Snapshots are stored separately (a snapshot store or a side stream), not by mutating events. They are a pure read-path optimization and leave the log untouched.
Heads-up Snapshots are an optimization layered on top of replay — you read the snapshot at version N then replay events after N. Full replay from genesis is still always available.
Heads-up Snapshots are taken periodically (every N events or on a schedule); their whole value is amortizing the fold cost, not capturing every event.
Quiz
Completed
OrderPlaced gains a required currency field. Millions of historical OrderPlaced events lack it. What is the standard approach?
Heads-up Mutating past events violates the append-only invariant, breaks every downstream replay and audit guarantee, and invalidates version-based concurrency. You never rewrite the log.
Heads-up Deleting history destroys the audit trail and temporal queries the pattern exists for, and leaves aggregates unbuildable. Upcasting preserves history while presenting the new shape.
Heads-up Null-checks leak schema history into every consumer indefinitely. Upcasting centralizes the fix in one transformation chain so domain code stays clean.
Quiz
Completed
A user exercises GDPR erasure; their PII is embedded across hundreds of immutable events. What does a senior actually ship?
Heads-up Rewriting the append-only log breaks every replay, destroys the audit trail, and invalidates optimistic-concurrency versions. Once you mutate history you no longer have event sourcing.
Heads-up Disk encryption guards against physical theft, not against your system retaining a subject's data after an erasure request. It does nothing for deletability of one person's data.
Heads-up That discards audit, temporal queries, and replay for the whole aggregate to solve a problem crypto-shredding handles surgically. It is a massive over-correction.
Recap
The through-line of the unit is one inversion and its consequences: the append-only log is the source of truth, current state is a fold, and everything else is derived. Projections are disposable read models rebuilt by replay, so reads are eventually consistent. Snapshots bound replay cost but drift silently if unguarded. Versioning is permanent — old shapes live forever, so you upcast instead of rewriting. And GDPR against an immutable log is met with crypto-shredding, with a real legal caveat. Every answer here resolves back to the same rule: never mutate the log; derive, replay, and transform around it.