Member-only story
Choosing a CQRS Architecture That Works for You
A comparison between the different types of CQRS architecture and how to choose the right one for your problem
Command Query Responsibility Segregation (CQRS) is a vast ocean of deep topics within The World of Software Architecture. It is often stigmatised with huge complexity, and many engineers are reluctant to dip their toes in the water.
Some great articles talk through complex, eventually consistent, distributed CQRS system architectures that can handle massive scale. If you are just getting started with CQRS, then this can be a little daunting. In reality, there are also much simpler options that work well for most problems.
Command Query Responsibility Segregation (CQRS)
CQRS splits data access into Commands and Queries.
- Commands: Write data – Create/Update/Delete
- Queries: Read data
Each Command and Query class has a corresponding Handler class. Generally, Commands and Queries are dispatched to their Handler using a synchronous in-process Mediator. Sometimes asynchronous methods, such as a Message Bus, are used for handling Commands when there are high-scale requirements.
Splitting Write and Read operations means we can optimise each side independently. This might mean different Write and Read models. It might even mean completely different databases. That choice depends on the non-functional requirements of your app.
Let’s talk through some of the options and when they can be used.
Single Read/Write Model, Single Database
This is the simplest flavour of CQRS, where our Commands and Queries use the same Model/Entity classes. For most small-to-medium-sized apps, this is generally fine!
