Summary
Event sourcing naturally produces a normalized write model (the event log) that CQRS separates from purpose-built read models (projections). Each pattern addresses what the other lacks: event sourcing provides audit and temporal query; CQRS provides fast reads without replay cost.
Evidence
- ·Event sourcing's write side (event log) is a natural CQRS command model: writes produce events, not mutable state
- ·CQRS read models (projections) are built by consuming the event stream, eliminating the need for expensive event replays on reads
- ·The combination enables independent scaling of read and write paths
- ·Greg Young's original CQRS formulation was developed alongside event sourcing patterns
- ·Netflix and LinkedIn engineering use event-sourced CQRS for their activity feed systems
Operational Context
- ·Projection lag is the primary operational concern: read models are eventually consistent with the event log
- ·Multiple independent projections can consume the same event stream, enabling diverse read models with no write-side changes
- ·Command handlers validate against the event-sourced aggregate state before appending new events
Tradeoffs
- ·Two models to maintain: event schema evolution affects both command handlers and projection logic
- ·Projection rebuild (full event replay) can take hours for mature systems with large event logs
- ·Debugging requires correlating commands, events, and projection state across three separate stores
Evidence grounding
Grounded, 5 supporting itemsEvent sourcing and CQRS are consistently co-recommended in distributed systems literature (Fowler, Vernon, Young). The two patterns are architecturally complementary and are rarely used independently in production at scale.