Event sourcing — storing events instead of state

Application needs complete audit trail of all changes. Need to rebuild state at any point in time. Traditional CRUD overwrites data, losing the history of how the current state was reached.

(1) Store every state change as an immutable event: OrderCreated, ItemAdded, PaymentProcessed. (2) Current state is derived by replaying events from the beginning. (3) Use snapshots to avoid replaying entire history: save state every N events, replay from last snapshot. (4) Event store: append-only database or purpose-built store (EventStoreDB, Kafka). (5) Projections: create read-optimized views by processing events. Different views for different query needs. (6) Combine with CQRS: separate write model (events) from read model (projections). (7) Challenges: event schema evolution (use upcasting), eventual consistency, replay performance. (8) Don't use event sourcing for simple CRUD — it's a significant complexity increase.

Event sourcing captures the full history of every change, enabling audit trails, temporal queries (what was the state at time X?), and debugging (replay events to reproduce bugs).