CQRS and CAP Theorem

The largest single benefit about CQRS is when you start running into problems with the CAP theorem. For those who are unaware, the basics of the CAP theorem are that there are three architectural properties that are linked together. Read through for a much better article describing CAP.

Consistency
Availability
Partitionability

The premise is that you can guarantee any two of these things. If you add one you do it by taking away from one (or both) of the others. In other words you can have a highly available consistent system but its partitionability will be low or you could have a highly available and partitionable system but you would likely need to give up on consistency.

 

Although it seems rather unrelated, CQRS and CAP have a very close relationship. You can use CQRS to get around problems you run into with CAP. The trick is that CQRS breaks up the system into multiple pieces that you can then adjust them separately. You are not avoiding CAP, you still have CAP limitations but you now have them in multiple places and you can make different choices in different places.

 

Let’s go through such a scenario. the customer needs all three; consistency, availability, and partitionability. Doing this in a single system according to CAP is impossible. But let’s get more into the problem and apply CQRS. We now have two distinct units, the first is the write side and the second is the read side. Where is consistency needed, is it everywhere or just for certain operations? How does our application scale? What is our ratio of reads to writes?

 

We can make different decisions on the read side and the write side. We can be ACID on the write side and BASE on the read side.

 

In most systems I see I find a ratio of reads to write between one and two orders of magnitude though I have seen this ratio up to six and higher orders of magnitude (consider a popular blog). So we can pretty quickly see that partitionability is important on the read side, it is what really controls our “perceived” partitionability, 90+% (in some cases up to five 9s) of our operations occur on the read side! On the write side we in most systems have a focus on not allowing in bad transactions and maintaining sanity within our data. We can give full consistency in most cases on the write side and give up a level of partitionability (not all systems but many, how many systems out there even process 1000 transactions per second? A modern RDBMS can easily handle this).

 

Coming back to the read side, if we have full consistency on the write model to validate transactions, do we actually need full consistency? What if the read model were 5 seconds behind the write model. Consider the popular blog example, what if when putting up a blog it took five seconds before it appeared throughout the whole site? This is in a human’s point of view a very short period of time and we will get very few conflicts introduced because of it (users generally take longer than this to edit data anyways, but that’s a post in and of itself)… but 5 seconds is an eternity in terms of a computers time. Introducing even just 1 second can allow our read model to become highly partitionable and available at very little cost in terms of user experience.

 

This is just one of the many examples of how we can make different decisions on the read side versus the write side. The ability to make these different decisions is really what CQRS is all about. Whether it be CAP decisions, storage model decisions, or hosting/platform decisions; all can vary independently. This is especially important because the architectural properties in all systems are different for reads than writes … I don’t have a formal proof but I cannot possibly think of a system where one will find an optimal solution that is the same for both.

 

Its important to note though, that these are things you can do, not necessarily things you should do. Separating the read and write models can be quite costly.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

One Response to CQRS and CAP Theorem

  1. Pingback: Szóste Spotkanie – Command-Query Responsibility Segregation | [sckrk] Software Craftsmanship in Kraków

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>