Event sourcing stores every state change as an immutable event instead of storing current state. To get current state, replay all events. An account balance isn't stored directly — it's calculated from the sequence: Deposited($100), Withdrew($30), Deposited($50) = $120.

How Event Sourcing Works

Traditional: UPDATE accounts SET balance = 120 WHERE id = 1. Event sourcing: INSERT events (AccountCreated, MoneyDeposited $100, MoneyWithdrawn $30, MoneyDeposited $50). Current balance = replay events. You get a complete audit trail, time-travel debugging, and the ability to rebuild state from any point.

Key Concepts

  • Event Store — Append-only log of all events — the source of truth for the system
  • Projections — Read-optimized views built by replaying events — rebuild when requirements change
  • Replay — Reconstruct state at any point in time by replaying events up to that moment

Frequently Asked Questions

When should I use event sourcing?

Financial systems, audit-critical applications, and collaborative systems (like Google Docs). The audit trail and time-travel capabilities are worth the complexity. Don't use it for simple CRUD apps.