CQRS is gaining popularity as a pattern suited for applications with high scalability and performance needs. In his article “CQRS On Windows Azure”, Mark Seemann uses an example to explore how to use this pattern with Windows Azure as the platform.
CQRS stands for Command Query Responsibility Segregation – this pattern is based on the notion that you can use a different model to update information than the model you use to read information. This allows you to treat reads and writes differently, possibly accessing different databases or using different data access technologies, and even using other architectural patterns like Eventual consistency and Event Sourcing. Some of the key points from the article -
- Always assume that Display Data is Stale and use UI to set expectations right (for instance data on the screen cannot provide any guarantees)
- While processing a request from the UI, create a command, send it (to a queue) and return as quickly as possible. On Windows Azure, this can be done by implementing a Channel on top of the Storage queues
- Separate Worker role(s) can pick the command messages sent from the UI and process it
- Make Writes Idempotent so that replaying a message multiple times does not cause data issues
- Use Optimistic Concurrency – in Windows Azure this can be done by using Etags (CloudBlob.Properties.ETag)
- Updating the View Data can happen asynchronously through another Channel – which can then be queried by the controllers
- Denormalize read data to improve read performance
A great place to know more about CQRS in general is Rinat Abdullin’s CQRS starting page. You can also read Martin-Fowler’s essay on the topic or a recent article on InfoQ “Healthy Architectures..” by Arunava Chatterji.