Why to start with an image? Simple, it’s generally recognized that 1 picture is worth 1000 words! And, this is really true for Engineers…
WMware Cloud Management Blog proposes an interesting article on the CQRS (Command and Query Responsibility Separation) Architectural Pattern an its applications, a worth reading. In this short blog post, few more words are spent to dig into the details of such Pattern.
Firstly, what is the general idea behind it? Simply, in a Complex Systems, separating the Data Domains in i. State Modifiers (parts of the Data Models dedicated to State transitions) and ii. State Readers (parts of the Data Models dedicated to the data retrieval) is highly beneficial both for Scalability and Availability, this at the same time allows to enforce policies for stringent SLA: for example, writes isolated from reads allow to predict with a good confidence the average response times that can be assumed as a Soft Real-time NFR (Non-Functional Requirement).
An analogy to understand the difference between State Modifiers and State Readers can be made using the OLTP Vs OLAP example: normally OLTP databases are used to store transactional data that makes the System evolve, quickly and in a safe way; on the other hand, OLAP cubes are just materialized views of the OLTP data used to perform sophisticated queries against the State of the System. OLTP and OLAP data are part of the same Data Model, but implements different concerns: OLTP systems/datastores are mostly addressed by writes/transactions, instead OLAP systems/datastores are addressed by read/retrievals, definitely faces of the same Data Model accommodating different concers.
From an architectural viewpoint, OLAP cubes are built up by replicating the Data from the OLTP databases: that is the foundation of the CQRS, having dedicated read-only datastores replicated from the write-only. Such an architectural pattern allows to scale separating reads from writes, having rooms for providing zones of availability; performances (another relevant aspect) are also improved by reducing the data races (writes never collide with reads).
Concluding, it is worth to remark that applications of this pattern are as many successful stories (see the OLTP Vs OLAP example discussed above) which are often well known to System/Software Architects.