What is event sourcing?

Event sourcing stores the state of a system as an immutable, ordered sequence of events (facts) rather than the current state. Instead of "user balance is $100," you store: "UserCreated," "Deposit $50," "Deposit $75," "Withdrawal $25" — and derive the current state by replaying all events. Key properties: (1) Immutable event log: never delete or update events — append only; (2) Event as source of truth: the current state is a projection/snapshot of past events; (3) Temporal queries: "what was the balance on Jan 15?" — replay events up to that date; (4) Full audit trail: every change is recorded with who made it, when, and why; (5) Replay: replay events to a new read model if you need a different view of the data; (6) Snapshots: periodically save the computed state to avoid replaying all events from the beginning. Benefits: complete audit log, temporal queries, easy debugging (replay to reproduce), multiple projections from same events, decouples state from storage, enables CQRS. Challenges: eventual consistency in projections, event schema evolution (old events must be readable by new code), performance of replaying large event streams (mitigated by snapshots), steep learning curve. Combined with CQRS: event sourcing naturally pairs with CQRS — write side stores events, read side projects events into query-optimized models. Used by: banking (every transaction is an event), e-commerce (order state machine), collaborative tools (Google Docs stores operations, not snapshots).