Event Sourcing & CQRS

Event sourcing stores the full history of what happened as an ordered, immutable log of events (e.g. OrderPlaced, ItemAdded, OrderShipped) rather than just the current state. Current state is reconstructed by replaying events from the beginning (or from a snapshot). Benefits: a complete audit trail, the ability to rebuild state or derive new projections retroactively, and temporal queries ("what did this look like last Tuesday?"). The trade-off is added complexity: you cannot simply UPDATE a row, and you must handle event schema evolution over time.

CQRS (Command Query Responsibility Segregation) splits the model that changes state (commands like "place order") from the model that reads state (queries like "show order history"). The two can use different data structures, stores, and scaling strategies — for instance a normalized write store and denormalized, query-optimized read stores. It often pairs with event sourcing: commands produce events, and read models (projections) are built by consuming those events. CQRS adds complexity and is overkill for simple CRUD, but shines when read and write workloads have very different shapes or scale needs.

A projection (or read model) is a derived, query-friendly representation built by processing the event log. Because the events are the source of truth, you can create many projections from the same stream — one denormalized table for a dashboard, another for search, another for reporting — each shaped for its queries. Projections are disposable: if you need a new view or fix a bug, you rebuild the projection by replaying events. They are typically eventually consistent with the write side, since they are updated asynchronously as events are processed.

An aggregate (from Domain-Driven Design) is a consistency boundary: a cluster of objects treated as one unit for data changes, with a single root entity through which all modifications flow. In event sourcing, the aggregate loads its state by replaying its events, validates an incoming command against its business rules (invariants), and — if valid — emits new events. All invariants must hold within a single aggregate transactionally; consistency across aggregates is handled asynchronously (often via sagas). Choosing aggregate boundaries well is the key design decision in these systems.

Eventual consistency arises because the write side commits an event, and projections consume it asynchronously to update read models. For a short interval, a freshly written change may not yet appear in queries — the read model "catches up" shortly after. This is a deliberate trade-off: decoupling reads from writes enables independent scaling and multiple specialized views, at the cost of immediate read-after-write consistency. Systems handle the UX implications by, for example, optimistically showing the user their own change while the projection updates, or surfacing a "processing" state.