What is CQRS? And why do we need it?

The other day I was explaining some key concepts of Domain Driven Design (DDD). One of the developers asked me about CQRS. I have noticed that a lot of developers start with CQRS to separate the read and write model when implementing DDD.

In this blog I will dive into: what is CQRS? And: what are the benefits and usage of CQRS with DDD?

What is CQRS?

Let’s start with the basics. CQRS stands for Command Query Responsibility Segregation.

Segregation (or split up) of responsibility (who do what) of actions that changes or alters state and actions that does not change state. We name actions that can change state Commands and name none-changing action Query.

So, CQRS is about separating what changes state and what doesn’t.

CQRS as an architectural pattern

CQRS is what we refer to as an architectural pattern and is not limited to a specific place in the software. The separation between reading and writing can happen in many places, like databases, code, or whole systems. CQRS is not a DDD requirement per se, but CQRS can be used well in conjunction when doing DDD.

Why do we need CQRS? 

In most applications when we access data, it is for the sake of reading the state, not for changing state. For example: in a webshop, you browse (read) way more items, than you add (write) to your basket. The optimizing effect of CQRS (separating a lot of reading from sometimes writing) in the application can have performance benefits and cost saving effects.

Eventual Consistency

The basis underneath all this separation of reading and writing, is eventual consistency. 

Eventual consistent means that a state change is not imminent projected. There is a delay. But the state change will eventually be reflected correctly.

If we go back to the webshop example: when we are looking at a specific product, let’s say yellow rubber ducks, you see next to the image of the rubber duck the number, for instance 17, of rubber ducks in stock. But that number may not be 100% accurate because there is a small time-gap between when the data of the image and numbers-of-items-in-stock is read from the database until it is displayed on your screen. During that time-gap the number of items-in-stock might have changed. Maybe someone returned a rubber duck, so the number could be 18. Or someone just purchased 3 rubber ducks, meaning that the actual number of Rubber ducks in stock is 14. 

---

This eventuality is what CQRS take advantage of. We do not need to see (read) 100% correct data all the time. In fact, in most cases it doesn’t matter at all, because the data is accurate enough for it to work. The only time data needs to be accurate is when someone tries to change the state (write) of the system by putting 8 rubber ducks in their webshop basket. So, by segregating reads from writes, commands from queries, we can increase the efficiency by leveraging on the nature of eventual consistency.

Do you want to learn more on DDD and CQRS? Do you need help implementing of these things? Register to one of our DDD training sessions.

To DDD Training Sessions