Event Sourcing

A persistence pattern where state is stored as a sequence of events rather than current values.

Event Sourcing is a persistence pattern where you store every change to your application state as an immutable event, rather than overwriting the current state. Instead of a users table with the latest values, you keep a log of events: UserRegistered, EmailChanged, AccountDeactivated. The current state is derived by replaying these events from the beginning.

This idea changes how you think about data. In traditional systems, you stores a snapshot: "the order total is $42." With Event Sourcing, you store the history: "item added ($20), item added ($30), discount applied (-$8)." You can always compute the current state, but you also know how you got there.

One benefit is a complete audit trail. In domains like finance, healthcare, or compliance, knowing what happened and when is not optional. With Event Sourcing, the audit log is the data model itself.

Event Sourcing pairs naturally with CQRS. Since the event log isn't optimized for reads, you can build separate read models to serve queries. With events, you can create denormalized views for specific use cases.

On the other hand, the setup can be complex. Replaying thousands of events to rebuild state gets slow, so you need snapshots. Changing event schemas over time requires careful Event Versioning. Debugging means reasoning about sequences of events rather than inspecting a row in a database. These are solvable problems, but it requires a mindset shift.

Event Sourcing is a powerful tool when the domain demands it. If you need a reliable audit trail, the ability to reconstruct past states, or temporal queries ("what was the account balance on March 5th?"), it's worth the investment. For simple CRUD applications, it can be overkill.