olivier deheurles

I’ve heard several colleagues of mine talking about CQRS and I spend some time today looking it.

If you want to understand what it is about please have a look here:
- AxomFramework (Java)
- NCQRS (.NET)
- Udi Dahan has a detailed post “Clarified CQRS”

Let’s have a look to the architecture diagram (I will use Udi’s one):

Figure 1: Udi’s CQRS architecture diagram

We are currently using this type of architecture in several areas for the project I’m working on, but the flow is actually different: user does not pull for data, it is pushed to him (or to be more accurate the client pulls the data once and is then notified of changes to stay in sync).

Let’s look at a real use case: the user is using a UI to trade in real-time. When the application starts-up the UI retrieves the list of trades for this user and, the same time, notifies the server of his interest for trade events (i.e. the server stores a subscription for this user).

Figure 2: Application start-up, trade subscription

You might say it does not looks like Udi’s diagram… Wait! We will get there.

Ok, now let’s look at what happens if the user decides to trade:

• a trade request (command) is send to an execution engine which will do lots of fancy checks (does this client has enough credit? Is the price valid? etc.). You have 2 possible output to this workflow: all checks pass and the trade is done or one of the check fails and the trade is rejected. We will focus here on the happy path
• as soon as the decision has been taken several things needs to happen:
  • the user needs to be acknowledged of the success or the failure of the transaction
  • the back office system needs to be notified (this is where the trades will actually be booked (other stored in a big database if you prefer)
  • other users needs to be notified of this trade: for instance the sales responsible of this client and other users belonging to the same client (client=company) want to be aware of this trade.

Figure 3: execution flow

Now the picture looks like the CQRS one but there is one major difference: the guy on the picture is looking the other way around. No, not this one… The trade notifications have been pushed to all users affected by the state change. If you look at the CQRS architecture the client is pulling for the data (the query).

Let’s review a typical user experience for a classical data driven app (or CQRS oriented):

• Bob opens order view with order 1
• Sara opens order view with order 1
• Bob modifies order 1
• Sara has stale data and she does not know yet
• Sara continue doing some stuff on order 1, have a coffee and a cigarette and finally commit 20 minutes latter her work
• At this stage 2 things can happen:
  • developers did not thought their systems could be used by more than 1 user at the same time and Bob just lost all his work: it has been overridden by Sara and he does not even know that it happened (he may figure out end of month when they will review all the orders)
  • developers did a better job and implemented optimistic locking and Sara is happy to learn that she can not save her work and has to do it again. She smashes her keyboard (which surprises Bob sitting right next to her) and she goes outside for another cigarette.

In both scenarios you could improve user experience by polling the server to see if the data has changed and notify the user if it’s the case, but this kind of architecture is not scalable, at all.

Pushing the data to the client when it changes is, from my perspective, a far better way to handle the problem:

• users are notified in real time when a particular piece of information has changed: there is still a time window where the data is stale for some users but this window is of the order of the second (or the millisecond if you add a few million $), not an undetermined amount of time. Optimistic locking is still required but conflicts are less likely to happen,
• this significantly improves users collaboration. And instead of notifying only when the data is changed, users can be notified who is currently working on the same piece of data with the same mechanisms: Sara see in the status bar that  “Bob is modifying this order” and she asks him to tell her when  he is done with this order. Sara is not stressed and do not need a cigarette.
• this architecture is a lot more scalable than a pull model and network traffic is significantly reduced

I don’t understand why CQRS, which is using asynchronous notification mechanism sever side is not applying the same technics for the client.

It is not harder to have the UI layer notified asynchronously: there are now lots of enterprise grade technologies out there accessible to everybody: 0MQ, RabbitMQ, and lots of http push (or COMET) servers can be used to implement what I just described here in LAN or over the web.

A push system would probably delay Sara’s cancer of a good couple of years…