Event Sourcing
Storing state as an append-only log of events, and deriving current state by replaying them — full history, perfect audit.
Event sourcing stores an application’s state not as the current values but as an immutable, append-only log of every event that ever changed it. Current state is derived by replaying the events. Nothing is overwritten, so you have a complete, auditable history and can reconstruct state at any past point.
Worked example: a bank account is not a “balance = $500” row but a log of Deposited($700), Withdrew($200); the balance is computed by folding over the events — and you can answer “what was the balance last Tuesday?” by replaying up to then. Gotcha: event sourcing gives audit and time-travel for free but adds real complexity — replaying a long log is slow (so you snapshot periodically), schema evolution of old events is tricky, and querying current state is awkward, which is exactly why it is usually paired with CQRS (build read-optimized projections from the events).