Remember to Start your Free Trial today! for Pluralsight to learn more about all of these topics!
Start a 10-day free trial at Pluralsight
What is CQRS?
The first thing to mention is that CQRS is just a pattern. It is not an architecture or style or framework. It is simply a pattern to follow for scaling large systems. It is built upon the more simple principle of Command Query Separation, “A method should either change the state of an object, or return a result, but not both”
Command Query Separation makes reasoning about objects easier and is broadly applicable.
CQRS is much more specific and not broadly applicable.
The problem that CQRS solves is Blocking the User when Locking the Data
This is commonly seen when you have a large set of people acting on a small set of data.
A good example would be when users would be trying to pick seats for an air plane. Many people may want the same seats. Only one person will end up with the seat and the others will have to try again. This is even worse when someone is trying to reserve seats for a family and wants several seats together. They will become blocked several times before they are able to get seats they may like.
Locking the data is necessary, you must ensure that only one person gets a seat. But, blocking the user in that process is not necessary.
One option would be to introduce a ticketing agent that takes everyone’s requests and assigns the seats and then lets the passengers know of their assignment. The users could then query the status of the seat assignments. But, what they can’t do is change the seating assignments. They can’t affect the seating assignment object directly. For that, they’ll need to go back to the ticket agent. This is not preferred either. There is no immediate feedback.
The first step is to separate out your commands/updates from your queries. You should never return information from a command. If you need to track any kind of status of a transaction, the caller should generate the identifier so that he can call back or query for that status at a later time. Don’t wait for the command to have to fully complete while the user is waiting and blocked.
This improves the situation programmatically by not creating any read locks on data when a user intends to update the same data that is being read by another. It avoids either user from becoming the victim of a deadlock.
It now becomes important to have a queue of messages to process. These can be processed in the order they were received or in a priority and never create any locks. At this point you can have a separate service that queries for the status of that transaction for completion. You can see my post about service bus implementation HERE.
The trade off you are making is Eventual Consistency for Availability. You are making the user experience better and never blocking with the small drawback of potentially stale data.
The CAP Theorem says you can only ever choose 2 of 3 for:
- Consistency – never receive old data
- Availability – reasonable response without an error
- Partition Tolerance – unavoidable because you can’t control the network
Some things you will want to make sure you keep in mind are:
- Persisting these messages in case of network problems/latency
- Guarantees of messages being processed
- Guarantees that messages won’t be duplicated
The next big benefit of CQRS is now that you have your commands separated from your queries, you can have different data models for each side. You don’t need large Data Transfer Objects that know about all the related data, know how to modify it, getters and setters, business logic etc.
Instead, you can have different models for different parts of the system. Depending who is asking for the data and what they need to do with it, they can query in different ways and only for the data that they need (say to display some of the data on a web page), and have their own model to do so. Since they don’t need to keep track of modifying this data, they don’t need all the extra cruft, extra data, all the rules etc. They can just ask for exactly what they want.
The commands can also be cut down in size to know how to modify the part of the data that it cares about.
This allows you to structure your applications in a way that they only care about the parts they are dealing with. You can have more specific commands and queries for specific data, that doesn’t necessarily represent the structure while in the database.
This also allows you to scale your architecture and hardware separately and independently of each other. If you need to support millions of queries, but only a handful of commands, you don’t need to scale them together. You get distinct optimization and huge scalability potential.
Some side effects of implementing this pattern is usually a simplified design, hassle free enhancements, and opens yourself up for some other event based architectures and design patterns.