What Is Event Sourcing? A Practical Guide
Traditional software systems store only the current state of data. If a user's balance is $500, the database simply says "500." How they got there? Unknown.
Event Sourcing fundamentally changes this approach: it records every change as an event.
The Core Concept
In Event Sourcing, state isn't stored directly. Instead, all events leading to the current state are stored chronologically:
Event 1: AccountOpened { user: "Alice", date: "2026-01-01" }
Event 2: MoneyDeposited { amount: 1000, date: "2026-01-05" }
Event 3: MoneyWithdrawn { amount: 300, date: "2026-01-10" }
Event 4: MoneyDeposited { amount: 200, date: "2026-01-15" }
Current balance? Replay the events: 0 + 1000 - 300 + 200 = $900
Why Event Sourcing?
1. Complete Audit Trail
Every change is recorded. Who changed what, and when? All answers are in the events. Essential for finance, healthcare, and legal domains.
2. Time Travel
You can reconstruct the state at any point in time. "What was this customer's balance 3 months ago?" — answered instantly.
3. Debugging Made Easy
When you find a bug, you can replay events to pinpoint exactly where the problem occurred.
4. Loose Coupling
Events are a perfect interface for inter-system communication. One service produces events, others consume them — without knowing each other.
Event Sourcing vs Traditional CRUD
| Feature | Traditional CRUD | Event Sourcing | |---------|-----------------|----------------| | Data storage | Current state | All events | | History | None | Complete | | Querying | Direct | Requires projection | | Complexity | Low | Higher | | Audit trail | Extra effort | Built-in | | Storage | Less | More |
Event Sourcing + CQRS
Event Sourcing is commonly paired with CQRS (Command Query Responsibility Segregation):
- Command side — Writes events (to the Event Store)
- Query side — Reads from projection tables built from events
This separation enables independent scaling of read and write operations.
When to Use Event Sourcing
✅ Good Fit
- Financial systems — Every transaction must be recorded
- E-commerce order tracking — Every stage of an order
- IoT data streams — Chronological sensor data
- Collaboration tools — Google Docs-style concurrent editing
❌ Poor Fit
- Simple CRUD applications
- Systems that don't need historical data
- Prototypes and MVPs
Practical Example: Order System
OrderCreated { id: "O001", items: [...], date: "..." }
PaymentReceived { orderId: "O001", amount: 250, method: "credit card" }
OrderPrepared { orderId: "O001", preparedBy: "Warehouse-A" }
ShippedToCarrier { orderId: "O001", trackingNo: "US123456" }
Delivered { orderId: "O001", deliveryDate: "..." }
With this event stream, you can:
- Know which stage the order is at
- Pinpoint exactly where a problem occurred
- Extract statistics (average delivery time, etc.)
Event Store Technologies
| Technology | Feature | |-----------|---------| | EventStoreDB | Purpose-built, most mature | | Apache Kafka | High-volume event streams | | PostgreSQL | Simple append-only table implementation | | DynamoDB | AWS ecosystem integration |
Conclusion
Event Sourcing is a powerful architectural pattern, but it's not for every project. It adds complexity, but offers strong advantages like complete audit trails, time travel, and loose coupling.
Learn Event Sourcing and other architectural patterns interactively on LabLudus. The Software Architecture 3.0 book covers distributed system patterns in chapters 4-6.