Event Sourcing is an architectural pattern where the state of your application is determined by a sequence of events, rather than just the current values.
In a traditional system (CRUD), a deposit simply updates the balance column. Here, we append an event. The balance is calculated by replaying history.
No events recorded yet.
Drag the slider to replay history. The state above is derived only from events up to the selected point.
Instead of saving the "Current State" (e.g., Balance: $500), we save the verb (the action) that happened.
User requests an action (e.g., "Deposit $100"). The system validates business rules here.
If valid, an immutable event (`MoneyDeposited`) is appended to the ledger. This is the write-side.
To show the balance on screen, we replay events or update a cached view. This is the read-side.
In banking, healthcare, or legal systems, knowing who did what and when is mandatory. Event sourcing gives you this for free.
A user reports a bug that happened last Tuesday? Copy the production event stream to your local machine and replay it to the exact moment of failure.
Want to know how many users withdrew money 5 minutes after depositing? With CRUD, that data is overwritten. With events, you can answer questions you haven't even asked yet.
When data changes, the old data is lost.
Data is never deleted, only appended.