Event Sourcing
Persist state as an immutable sequence of business events: Event stores, state rehydration (fold/reduce), periodic snapshots, optimistic concurrency, and auditability.
01.1. What is Event Sourcing?
In traditional CRUD (Create, Read, Update, Delete) architectures, databases persist only the current state of an entity. When an account balance changes, an UPDATE accounts SET balance = balance - 50 WHERE id = 101 statement executes. The previous balance and the exact business intent behind the modification are permanently overwritten and destroyed.
Event Sourcing fundamentally changes how state is modeled:
- Instead of mutating records, the system records all state modifications as an append-only, immutable stream of domain events.
- An event represents an immutable fact that occurred in the past (e.g.,
AccountOpened,FundsDeposited,DebitCardBlocked). - Current state is a derived projection: State is not stored directly; it is computed dynamically by rehydrating (folding/reducing) historical events from the beginning of time:
CurrentState = reduce\Big(InitialState, [Event_1, Event_2, \dots, Event_n]\Big)
Traditional CRUD State Mutation vs Event Sourced State Rehydration
Traditional CRUD State Mutation vs Event Sourced State Rehydration
Deriving aggregate state by replaying immutable domain events from periodic snapshots.
Unlock Topic #119: Event Sourcing
You are viewing a preview. The full in-depth engineering deep dive, interactive simulators, architecture flowcharts, and self-assessment quizzes for this topic are available with Pro or Lifetime Access.
Failure modes, high-throughput bottlenecks, and real FAANG implementation decisions.
Interactive system topology diagrams, live parameter simulators, and downloadable SVG charts.
Staff-level multiple-choice quiz questions with instant feedback and answer explanations.
Firebase Google authentication automatically syncs your completed topics and quiz scores.
How clear and staff-actionable was this system breakdown?