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.
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).
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.