Event sourcing

Problem

Traditional state-based storage loses history: you know the current balance, but not why it's that value. Auditing, replay, and temporal queries are hard.

Context

Domains with strong audit requirements (finance, healthcare) or complex state transitions (order lifecycle, workflow) where the sequence of events matters.

Solution

Persist every state change as an immutable event ('deposit $100', 'withdraw $30'). The current state is derived by replaying events. New events can be added; old events cannot be modified. Read models are built by projecting events.

Trade-offs

• Event log grows forever — snapshots + archival for old events
• Rebuilding current state requires replaying events (slow if you have millions)
• Event schema evolution is a major concern — old events must remain readable
• Not a natural fit for CRUD operations — feels heavy for simple domains

Failure modes

• Bad event permanently in log; must add compensating event, can't delete
• Projection code has a bug — replaying fixes it, but re-projecting a billion events is expensive
• Event ordering assumptions violated by concurrent writes

When to use

• Financial ledgers
• Complex workflow / order lifecycles
• You need to prove 'this is what happened' for compliance
• You want temporal queries ('what did this look like on Jan 1')

When NOT to use

• Simple CRUD apps — huge overhead
• High-frequency updates to the same aggregate — projection cost dominates
• Team unfamiliar with event-sourcing patterns