Back to Catalog
Microservices
Data Management
Event Sourcing
Don't store state — store every event that led to it. Replay to reconstruct.
Intent & Description
Real-world Use Case
Order aggregate: OrderCreated → ItemAdded → PaymentProcessed → OrderShipped. To get current state, replay all 4 events. Want audit history? It’s all right there. Want to replay a bug? Replay to that timestamp.
Source
📌 TL;DR
Event Sourcing = your database is an append-only log of “what happened.” Replay to get state. Complex to operate, powerful in capability.
Advantages
- Atomic publish — event IS the state change, no dual-write
- Built-in full audit log of every state change
- Enable temporal queries — “what was the state at time T?”
- Natural integration with CQRS and event-driven architectures
Disadvantages
- Query current state requires event replay (mitigate with snapshots)
- Event schema evolution is hard — old events must stay valid
- Steep learning curve — paradigm shift from CRUD thinking
- Eventual consistency across read models