CQRS
Pattern separating read and write operations into distinct models, optimizing each independently for performance and scalability.
seed#cqrs#architecture#patterns#event-sourcing#read-write#scaling
What it is
CQRS (Command Query Responsibility Segregation) separates write operations (commands) from read operations (queries) into different models. Each side can use its own database, schema, and scaling strategy.
Why separate?
- Reads and writes have different access patterns
- Reads are usually more frequent (10:1 or more)
- Each side can scale independently
- Read models can be denormalized for speed
Typical flow
Command → Write Model → Event → Read Model (projection)
Query → Read Model → Response
CQRS + Event Sourcing
CQRS is frequently combined with event sourcing: commands generate events, and read projections are built from those events.
When to use
- Very different read/write patterns
- Need for multiple views of the same data
- Systems with high read load
When NOT to use
- Simple CRUD
- Immediate consistency required
- Team without distributed systems experience
Why it matters
CQRS enables optimizing reads and writes independently, which is essential in systems where query patterns differ radically from write patterns. Combined with event sourcing, it enables complete auditing and specialized projections.
References
- CQRS — Martin Fowler.
- CQRS Pattern — Azure — Microsoft, 2024. Pattern implementation guide.
- CQRS Pattern — Event Store — Event Store, 2024. CQRS with event sourcing.