Event Sourcing & CQRS

Storing the "why," not just the "what"

A normal table overwrites a row on every update — the balance went from $100 to $150, and the $100 is gone forever. Event sourcing stores the append-only sequence of events that got you there instead: AccountOpened, MoneyDeposited(50). Current state is just "replay the events, in order." Nothing is ever lost, so "why is the balance wrong" has an actual answer: read the log.

What this buys you

A perfect audit trail (every event ever is still there — regulators and support tickets love this), the ability to rebuild any past state by replaying up to a point in time, and the freedom to add a new read model later derived from the same history you already have, without migrating a single row — you just replay the existing events through the new logic.

CQRS: because one shape rarely serves both sides

Command Query Responsibility Segregation separates the model that handles writes from the model(s) that serve reads. The write side enforces invariants ("can't withdraw below zero") on the event stream; one or more read sides are precomputed, denormalized projections built from that stream, tuned for whatever query the UI actually needs — a dashboard view, a search index, a report. Event sourcing and CQRS pair naturally: the event log is the single write-side truth, and every read model is just another projection of it, rebuildable from scratch if its logic changes.

The cost side, honestly

Replaying millions of events to answer "what's the balance" is slow, so production systems use snapshots (periodic "state as of event #50,000") plus only replaying events after the snapshot. Debugging also shifts: instead of "what's wrong with this row," you're reasoning about a sequence of events and a projection — a real learning curve, and overkill for a CRUD app that just needs current state.

Remember this

• Store what happened, not just what's true now — state is derived, not stored directly.
• CQRS separates write correctness from read-shape flexibility — different models for different jobs.
• Snapshots make replay practical; without them, event sourcing doesn't scale to large histories.