Most systems store only the latest state. If a user changes their email, the old email is replaced. If an order is cancelled, the order row now says cancelled. That is simple and often exactly right.

The problem appears when history matters. Why is this account balance what it is? What happened to this order before it was cancelled? Who changed this setting, and when? If you only store the latest value, those answers are gone unless you built a separate audit trail.

Event sourcing keeps the history as the main record. Instead of overwriting state, the system stores each accepted change as an event:

The current state is rebuilt by applying those events in order.

That gives you a powerful audit trail, but it is not free. It changes how you write data, query data, evolve event formats, handle privacy, and operate the system.

This chapter explains event sourcing in practical terms: how it differs from normal state-based storage, how event streams work, how current state is rebuilt, what snapshots and read models are, how commands are handled safely, and when the pattern is worth the extra complexity.