To become a software crafter…Or die in the attempt.

A few myths about CQRS

I’m happy to see that event driven architecture rises in popularity, I already explained why I believe it makes sense. But when a topic gets more traction, we hear more and more weird things. Let me try to clarify a few myths about Command and Query Responsibility Segregation (CQRS) here.


CQRS is not Events Sourcing (which is not Event Storming)

Some people understand CQRS/ES as a single architecture paradigm. It’s actually two different paradigms, even is they were brought out together .

CQRS is about segregation of the commands and the queries in a system. It is nothing but Single Responsibility Principle (SRP) apply to separate the decisions from the effects. It comes from CQS.

Event Sourcing (ES) is about storing immutable events as the source of truth to derive any state of the whole system at any time.

Both paradigms work well together (Greg Young calls them “symbiotic”). But we can do CQRS without ES, and we can do ES without CQRS.

And just because I heard the confusion a few times, Event Storming is not Event Sourcing. It is not an architecture paradigm. Event Storming is a way to crunch knowledge with the business in an event driven approach, but it is not technical at all. It is a convention to talk with other people using post-its to represent business events.


CQRS is not Eventual Consistency

Eventual Consistency is when the read model is not synchronously updated with the write model.

It could be challenging, but it’s not mandatory in a CQRS system. We can choose to keep things synchronous, when it is good enough. We can go for an asynchronous implementation when we meet performance issue.

Thus Eventual Consistency is about performance, not about CQRS.


CQRS is not noSql and/or 2 databases

When I asked Greg Young what’s CQRS, he asks me in return if I know the concept of a SQL View. A View is nothing but a projection of the data, optimized for reading. That’s the query part of the system.

Sure, we can choose to store the query part in a separate database. Yes, it could make sense to store it in a noSql database, to reduce the impedance mismatch.

But it is CQRS as soon as there is a logical separation between command and queries. The rest is just a technical choice.

vector silhouette of a girl with raised hands and broken chains

CQRS is freedom

CQRS is before all freedom in architecture.
It allows choosing if we need eventual consistency, noSql, synchronous or asynchronous validation, and so on. It’s not an extremely complex topic, only useful for Amazon or Google.

Of course, CQRS is not a silver bullet either, but so far I have seen lots of missing opportunities to use it in several domains. But I still haven’t seen a software using CQRS where they should have go for a simple CRUD system instead.


PS: I just saw Greg has written on the same subject in a  more concise and direct way 3 years ago.

PS2: If you want to know more, I’ll be talking about the synergy between CQRS, ES and DDD, at BDXIO next October the 21st


One thought on “A few myths about CQRS

Leave a Reply

Your email address will not be published. Required fields are marked *