Store events, not current state
Day 117 of 149
👉 Full deep-dive with code examples
The Bank Statement Analogy
Your bank doesn't just show your balance:
- It keeps every transaction ever
- Deposit $100, withdraw $20, transfer $50...
- You can see exactly HOW you got to your current balance
Event Sourcing stores all the events that happened!
Not just the final result, but every step along the way.
The Problem It Solves
Traditional databases store current state:
- "User has $500 in account"
- But how did they get there?
- What happened yesterday?
If you only store current state:
- Can't answer "what changed?"
- Can't undo mistakes easily
- Can't understand the journey
How Event Sourcing Works
Instead of storing just the result:
Traditional: { balance: $500 }
Event Sourcing:
1. AccountCreated (initial: $0)
2. Deposited $1000
3. Withdrew $300
4. Transferred $200 to Friend
5. Deposited $0 (fee charged mistake?)
Current balance = replay all events = $500
Every change is an event, stored forever.
Benefits
- Complete history → See exactly what happened
- Time travel → Rebuild state at any point in time
- Audit trail → Perfect for compliance
- Debug easily → Replay events to find issues
- Undo/redo → Just remove or replay events
When To Use It
Great for:
- Financial systems (need full audit trail)
- Shopping carts (track user journey)
- Gaming (replay matches)
- Collaboration tools (track all changes)
Not needed for simple apps where you don't care about history.
The Trade-Off
- More storage → You're keeping everything
- More complexity → Rebuilding state takes work
- Worth it → When history matters!
In One Sentence
Event Sourcing stores every change as an event, so you can trace how things reached their current state.
🔗 Enjoying these? Follow for daily ELI5 explanations!
Making complex tech concepts simple, one day at a time.
Top comments (0)