CQRS and Event Sourcing Patterns
Expert guidance for implementing Command Query Responsibility Segregation (CQRS) and Event Sourcing patterns to build scalable, auditable systems with complete historical tracking and optimized read/write models.
When to Use This Skill
- Building systems requiring complete audit trails and compliance
- Implementing temporal queries ("show me the state at time T")
- Designing high-scale applications with complex domain logic
- Creating systems with significantly different read and write patterns
- Building event-driven architectures with historical replay capability
- Implementing systems requiring multiple read model projections
- Designing applications where understanding "what happened" is critical
- Building collaborative systems with conflict resolution needs
Core Principles
1. Command Query Separation
Separate operations that change state (commands) from operations that read state (queries).
| Commands (Write) | Queries (Read) |
|---|---|
| Express intent (CreateOrder, UpdatePrice) | Return data, never change state |
| Can be rejected (validation failures) | Can be cached and optimized |
| Return success/failure, not data | Multiple models for different needs |
| Change system state | Eventually consistent with writes |
2. Events as Source of Truth
Store state changes as immutable events rather than current state snapshots.
Traditional: Store what IS → UPDATE users SET email = 'new@email.com'
Event Sourcing: Store what HAPPENED → APPEND UserEmailChanged event
Result: Complete history, temporal queries, audit trail
3. Eventual Consistency
Accept temporary inconsistency between write and read models for scalability.
4. Domain-Driven Design Integration
- Aggregates enforce business invariants
- Events represent domain facts
- Commands express domain operations
- Bounded contexts define consistency boundaries
Quick Reference
| Task | Load reference |
|---|---|
| CQRS implementation patterns | skills/cqrs-event-sourcing/references/cqrs-patterns.md |
| Event sourcing & snapshots | skills/cqrs-event-sourcing/references/event-sourcing.md |
| EventStoreDB & Axon Framework | skills/cqrs-event-sourcing/references/event-store-tech.md |
| Consistency patterns | skills/cqrs-event-sourcing/references/consistency-patterns.md |
| Best practices checklist | skills/cqrs-event-sourcing/references/best-practices.md |
Workflow
- Identify if CQRS/ES is appropriate (high audit, temporal, or scale needs)
- Design commands expressing user intent
- Define events as immutable facts (past tense naming)
- Implement aggregates as consistency boundaries
- Create projections optimized for specific query needs
- Handle eventual consistency across bounded contexts
Common Mistakes
- Using CQRS for simple CRUD applications (overkill)
- Large aggregates that span multiple consistency boundaries
- Modifying or deleting events after publication
- Skipping command validation before aggregate processing
- Missing idempotency in event handlers
- No versioning strategy for event schema evolution
- Tight coupling between aggregates (use ID references only)
Resources
- Books: "Implementing Domain-Driven Design" (Vernon), "Event Sourcing & CQRS" (Betts et al)
- Sites: cqrs.wordpress.com, eventstore.com/blog, axoniq.io/resources
- Tools: EventStoreDB, Axon Framework, Marten, Eventuous
- Patterns: Event Sourcing, CQRS, Process Manager, Saga, Snapshot