CQRS and Event Sourcing

CQRS and Event Sourcing are powerful patterns for building scalable, auditable systems.

CQRS — Command Query Responsibility Segregation

Separate the write model (Commands) from the read model (Queries).

Write Path:
Client → Command → Command Handler → Write DB

Read Path:
Client → Query → Query Handler → Read DB (optimized)

Benefits:

• Write and read models optimized independently
• Read replicas can use different storage (e.g., Elasticsearch)
• Independent scaling

Event Sourcing

Instead of storing current state, store all state-changing events.

Traditional: { balance: 1000 }

Event Sourced:
  AccountCreated { balance: 0 }
  MoneyDeposited { amount: 1500 }
  MoneyWithdrawn { amount: 500 }
  → Current state: 1000

Benefits:

• Complete audit trail
• Time travel (rebuild state at any point)
• Event replay for new projections
• Natural Kafka integration

Combined Architecture

Command → Event Store → Kafka
                           ↓
                     Event Handlers
                           ↓
                  Read Projections (SQL, Elastic)

When to Use

• Financial systems requiring full audit trail
• Complex domain logic
• Systems needing multiple read models

Pitfalls

• Schema evolution is complex
• Querying is indirect
• Eventual consistency between write and read models

Conclusion

CQRS + Event Sourcing are powerful but complex. Use them when audit trails, multiple read models, or extreme scale is required.