What is CQRS?

July 6, 2016

CQRS is short for the command query responsibility separation pattern. This post traces the history of this pattern, the benefits, and discusses two common stumbling blocks: error handling and data validation.

Empty footbridge leading to a jungle. class=
© 2015 Tim Swaan for Unsplash

The processing of commands and queries is fundamentally asymmetrical …

A Command modifies state.

A command does something but does not return a result. Eiffel: a language for software engineering (PDF, p. 22)

A Query reports the current state.

A query returns a result but does not change the state. Ibid

Command methods go in one object; query methods in another.

This is the bit Greg Young added to create CQRS.

Otherwise, this pattern is the same as Bertrand Meyer’s Command and Query Separation principal, which

states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, Asking a question should not change the answer. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.

So what’s the big deal?

In my experience, the database becomes the tight resource in a big system. This CQRS pattern allows you to separate the write data model from the read data model, and this means:

Decoupling the read and write models forces you to figure out how to feed the read side from the write side. The most common approach is to use events; every command emits one or more events. The read model subscribes to those events and updates their state. (Note that this event sourcing is not required as part of CQRS.)

Using events to integrate the read and write models has some nice properties:

How to you ensure uniqueness?

In CQRS, the command processors do not access read models. (They are split. Completely.) This leads to a a common question: how do to validate the command data?

The problem I’ve come to now is validation. Every post have a shortUrl, and the shortUrl should be unique, but where should I put this validation in the domain?

I have seen two different answers.

  1. Accept eventual consistency and deal with this manually. Eventual Consistency and Set Validation (Greg Young, 2010) It is low cost and low frequency and it is cheaper to just send an email and fix it manually.
  2. The command processor should store enough state that it can ensure business rules are met. CQRS/Event Sourcing, how get consistent data to apply business rules? (Chris Baxter, 2012) In this specific instance, the command processor should keep a list of all current short urls. Access to that list should be synchronized.

The second answer is from Domain Driven Design, and is my preferred approach. I should be so blessed to have written a system so popular that the first approach is required!

How to you handle errors?

If the data sent by a command is invalid, and a command cannot return a value, how do you report an error back to the client?

The general consensus is to raise an exception. CQRS FAQ: Testing (Edument)

To me, raising an exception performs the same function as returning a value, which breaks Meyer’s rule. Which leaves two choices:

  1. return a value and break Meyer’s command rule, or
  2. don’t return a value and expose a query that retrieves the error state.

I’ll need to play around with this when I start building something real …

Change Log

Aug. 17, 2016


If you see an error or something that could be improved, please let me know. This is a blog about me learning, so I expect I will get some stuff wrong. The best way to reach me is by email: mkbucc1234@gmail.com (after deleting all the numbers).

To make a comment, check for a thread on the erlang subreddit and if there isn't one, then start one up.

Follow on Twitter: @mbucc

Back to the index.