All patterns
Data architecture
CQRS + Event Sourcing
Separate read and write models; store state as a sequence of events
Commands append events to an event store; projections build optimized read models. Powerful for audit and temporal queries; adds significant design and operational complexity.
Enterprise scalehigh complexity
Architecture diagram
High-level component relationships
Key components
Command side
Validates and emits domain events
Event store
Append-only log — source of truth
Projections
Materialize SQL, search, or cache views
Query side
Read-optimized APIs separate from writes
Data flow
- Command produces one or more domain events
- Events persisted append-only; aggregate rebuilt by replay
- Projectors update read databases asynchronously
- Queries never hit the write model directly
Pros
- Complete audit history and time-travel debugging
- Read models tuned per use case (reports, dashboards, APIs)
- Flexible downstream consumers via event replay
Cons
- Steep learning curve and more moving parts
- Event schema migration requires careful upcasting
- UI must handle lag on read models
- Overkill for simple CRUD domains
When to use
- Financial ledgers, healthcare records, collaborative editing
- Complex domains with rich audit requirements
- Read patterns differ drastically from write patterns
When to avoid
- Basic admin panels and CRUD APIs
- Team new to distributed data patterns
Real-world examples
- Banking transaction cores
- Inventory ledgers
- Collaborative docs (some designs)
Related technologies
EventStoreDBAxon FrameworkKafka + ksqlDB