Most systems store the current state of an entity: a row in a accounts table says the balance is $847.32. When something changes, you UPDATE the row. The previous state is gone. Event sourcing inverts this: you store an append-only log of every change that ever happened, and derive current state by replaying those events.

Instead of UPDATE accounts SET balance = 847.32, you append events like Deposited($500), Withdrew($150), InterestAccrued($2.32). Current balance is a fold over the event stream.

Why bother?

• Perfect audit trail. You can answer "what was this account's balance on March 14 at 2pm?" by replaying events up to that timestamp. Try doing that with an UPDATE-based schema.
• Temporal queries become trivial. Compliance asks "show every state this loan was in during 2025" — that's a filter on the event log, not an archeology dig through audit tables.
• New projections are free. Marketing wants a "longest streak of consecutive deposits" report? Replay the events into a new read model. No backfill scripts.
• Debugging gets surgical. Production bug? Replay the exact event sequence in staging and watch it happen.

Real-world example: Git is event sourcing. Each commit is an event. The working directory is a projection (a fold over commits). git log is the event stream. git checkout <sha> is "replay up to this point." You'd never accept a version control system that only stored the current files — yet most business systems work exactly that way.

The costs are real. Event schemas evolve, so you need versioning and upcasters (functions that translate old event shapes into new ones). Replaying millions of events to compute current state is slow, so you snapshot periodically — store the state at event N, then only replay from N forward. Rule of thumb: snapshot every 100-500 events per aggregate. If average replay takes more than 100ms, snapshot more aggressively.

When NOT to use it: Simple CRUD apps where nobody cares about history. A blog's comment table doesn't need event sourcing. Reach for it when audit, temporal queries, or evolving read models are first-class requirements — banking, healthcare, logistics, anywhere a regulator might ask "prove what happened."

Pair it with CQRS: the event log is your write model, projections are your read models. They're symbiotic patterns.