Event Sourcing

The Bank Statement Analogy

Imagine you are looking at your bank account online and your balance is $1,000.

In a traditional database (CRUD), the system literally stores the number 1000 in a table row next to your name. If you deposit $200, the system overwrites the 1000 with 1200. The old state is gone forever. If there's a bug and your balance is suddenly $0, you have no idea how it got there.

A bank doesn't actually work this way. A bank uses Event Sourcing.

Instead of storing your current balance, the bank stores a sequence of transactions (events):

1. Account Opened
2. Deposited $500
3. Deposited $600
4. Withdrew $100

To find out your current balance, the bank simply takes a starting balance of $0 and replays all the events in order. The current state is a derivative of the events.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

The Order Service appends immutable events to the Event Store. The Event Store fans out to a Read Projection (for fast current-state queries) and an Analytics Engine (for historical analysis). The original event log is never modified.

1 / 10.5×1×2×3×Playground

Events are appended to an immutable log. The log fans out to a Read Projection for fast queries and an Analytics Engine for historical analysis.

What is Event Sourcing?

Event Sourcing is a design pattern where the state of a system is determined by a sequence of events.

Instead of updating a record in a database, every change to the application state is captured as an immutable event object and appended to an append-only log (an Event Store).

Core Concepts

1. Immutable Events: Events are facts about something that happened in the past. They are named in the past tense (e.g., ItemAddedToCart, OrderShipped). Once an event is written, it can never be changed or deleted.
2. Rehydration / Replay: To get the current state of an entity (like a Shopping Cart), you load all the events associated with that cart and apply them sequentially.
3. Projections: Replaying thousands of events every time a user loads a page is slow. So, systems create "Projections"—read-optimized views of the current state that are updated whenever a new event is saved. (This pairs perfectly with the CQRS pattern).

Real-World Examples

1. Version Control (Git)

Git is the ultimate event sourcing system. Your codebase isn't saved as a massive snapshot every time you work. Instead, Git saves a sequence of diffs (commits/events). To get the current state of a file, Git replays all the commits applied to that file over time. You can time-travel to any point in the past by just stopping the replay early!

2. E-Commerce Shopping Carts

Amazon wants to know everything you do. If they just stored your current cart state, they wouldn't know that you added a TV, removed it, added it again, and finally bought it. By using Event Sourcing, they store every action: ItemAdded, ItemRemoved. Their analytics engine can later mine this event log to discover that people frequently remove that specific TV before buying, maybe hinting at a confusing price display.

Why use it?

Summary

Event Sourcing replaces the "update-in-place" database model with an append-only log of domain events. By storing every state change as an immutable fact, you gain a complete audit trail, the ability to reconstruct historical states, and deep business insights. The trade-off is a significant shift in how you model and query data.