# Event Sourcing

> Don't store state — store every event that led to it. Replay to reconstruct.

- **Category**: Microservices
- **Subcategory**: Data Management
- **Canonical URL**: https://designpattern.fyi/patterns/event_sourcing/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
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.





## Trade-offs


### 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




### Considerations & Drawbacks

- 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







---
**Reference**: [Original Source](https://microservices.io/patterns/data/event-sourcing.html)