Event Sourcing stores state changes as a sequence of events. CQRS separates read and write operations. Together, they enable powerful patterns for complex systems.
What is Event Sourcing?
Traditional State Storage
Traditional approach:
┌─────────────────────────────────┐
│ Account │
│ ───────── │
│ id: acc_123 │
│ balance: $500 │
│ status: active │
└─────────────────────────────────┘
Question: How did we get to $500?
Answer: Unknown 🤷
Event Sourcing Approach
Event sourcing approach:
┌─────────────────────────────────┐
│ Events for acc_123 │
│ ───────────────── │
│ 1. AccountOpened($0) │
│ 2. MoneyDeposited($1000) │
│ 3. MoneyWithdrawn($300) │
│ 4. MoneyWithdrawn($200) │
└─────────────────────────────────┘
Current state: $1000 - $300 - $200 = $500
Full history available ✓
Implementing Event Sourcing
Event Store
Loading code block...
Aggregate with Events
Loading code block...
Repository
Loading code block...
CQRS (Command Query Responsibility Segregation)
The Problem
Without CQRS:
┌─────────────────────────────────────┐
│ Same model for reads and writes │
│ ───────────────────────────────── │
│ - Write optimized for consistency │
│ - Read needs denormalized data │
│ - Conflicts in design decisions │
└─────────────────────────────────────┘
CQRS Solution
With CQRS:
┌─────────────────┐ ┌─────────────────┐
│ Write Model │ │ Read Model │
│ ───────────── │ │ ───────────── │
│ - Commands │ │ - Queries │
│ - Aggregates │ │ - Projections │
│ - Consistency │ │ - Optimized │
└────────┬────────┘ └────────▲────────┘
│ │
│ ┌─────────┐ │
└────▶│ Events │───────┘
└─────────┘
Write Side
Loading code block...
Read Side (Projections)
Loading code block...
Snapshots
Loading code block...
Benefits and Trade-offs
Benefits
✓ Complete audit trail
✓ Time travel (rebuild state at any point)
✓ Event replay for debugging
✓ Separate read/write optimization
✓ Scalable read models
✓ Easy to add new projections
Trade-offs
✗ Increased complexity
✗ Eventual consistency between read/write
✗ Event schema evolution challenges
✗ More infrastructure (event store, projections)
✗ Learning curve
When to Use
Good fit:
- Audit requirements
- Complex domain with many state transitions
- Need for multiple read models
- High read/write ratio
Not ideal:
- Simple CRUD applications
- Strong consistency requirements
- Small teams without event sourcing experience
Conclusion
Event sourcing and CQRS are powerful patterns for complex domains. They provide complete audit trails, enable flexible read models, and support scalable architectures.
Start simple: event sourcing alone adds significant value. Add CQRS when you need optimized read models. The patterns work best together but aren't required to be used together.