Event sourcing
A pattern where you store all changes as an immutable sequence of events instead of just saving the current state. The current state is derived by replaying the events. Gives full history, audit, and the ability to "time travel".
Idea: instead of UPDATE account SET balance = 100 you store events ("DepositedMoney 50", "Withdrew 20") → the balance is the sum of the events. Win: a complete audit history for free, the ability to reconstruct state at any point in time, and to build new views after the fact by replaying the log. Often paired with CQRS (separate read/write models) and "projections" (materialized views of the event stream). Trade-off: complex — schema evolution of old events, snapshots needed for performance, eventual consistency between write and read models. Use case: finance, e-commerce, domains where the "why" and history are central (DDD). Tools: EventStoreDB, Kafka as the log. Related to append-only logs and ledger databases.