CQRS Pattern
Separate read and write models to scale queries independently from commands. Command Query Responsibility Segregation keeps your domain clean and your database fast.
Why CQRS
In a single-model architecture, the same entity serves both reads and writes. As traffic grows, complex queries collide with transactional integrity. CQRS splits the path — commands mutate state, queries project it into optimized read shapes.
The Split
Command Side
- • Write-optimized schema
- • Domain aggregates enforce invariants
- • Event sourcing optional
- • Strong consistency
Query Side
- • Denormalized read models
- • Materialized views or separate DB
- • Eventually consistent
- • Blazing fast reads
Sync Strategy
After a command succeeds, publish a domain event. A projector listens, updates the read model. Use a transactional outbox to guarantee delivery. For low-latency needs, project synchronously within the same process.
When to Use
CQRS shines when read and write workloads differ dramatically — dashboards, search-heavy apps, audit logs. Skip it for simple CRUD where the overhead outweighs the benefit.
Next: Event Sourcing — persist every state change as an immutable event.