Lesson 03: State is a function of history

Event Sourcing

In traditional databases, you store the current state of the world. If Alice deposits $100, you run UPDATE accounts SET balance = 100. The old value of the balance is overwritten and lost forever.

Event Sourcing turns this upside down. You do not store the state. You only store an immutable, append-only log of events that happened. The current state is simply derived by replaying the events.

State = fold(Events, InitialState)

Time-Travel Bank Account

Use the slider at the bottom to "time travel" through the immutable event log. Watch how the current balance is calculated dynamically by replaying the active events.

Immutable Event Log (Append Only)

E01 AccountCreated +$100

E02 WithdrewATM -$20

E03 PaycheckDeposit +$50

E04 BoughtGroceries -$200

E05 RefundProcessed +$80

Time Machine (Replay Events)

Derived Current State

$10

Why do this?

Event Sourcing offers incredible benefits for complex systems:

Perfect Auditability: You never lose data. You know exactly why a user's balance is $10.
Time Travel: You can query the exact state of the system as it was last Tuesday at 2:00 PM.
Bug Recovery: If a bug corrupted your current state, you can fix the bug, wipe the state, and replay the event log to rebuild a perfectly correct state.

But Event Sourcing creates a huge volume of data. How do we process millions of events efficiently? We use Stream Processing systems like Apache Kafka.

Check yourself

1. What is the fundamental principle of Event Sourcing?

Event Sourcing treats the database as an immutable ledger. Current state is just a left-fold over the history of events.

Next: Stream Processing →