Read Model and Write model…what they are and from where they have been driven. In this blog we’ll discuss about CQRS, read model and write model in brief.
CQRS – What, Why and How … ?
Till the time we have used a number of different architectures, patterns and implementations that revolve around the core concept of Command Query separation (CQS). The core ideas behind such principle is to create code that targeted to a single purpose, generally side-effect free and easier to work with and maintain.
The problem with such traditional architecture is, the same data model is used to query and update a database. That’s simple and works well for basic CRUD operations. In case of more complex problems they are unwieldy.
Thus we introduced CQRS. CQRS is an abbreviation of Command and Query Responsibility Segregation. It is a useful pattern to reason about the activities of a specific domain. But it definitely comes with a steep learning curve. Reads, Writes, DDD, Event Sourcing, Eventual Consistency.
So the questions arose is that do we really need CQRS. Let’s take a moment and thinks about it. CQRS was atypical years ago, but nowadays we can find a lot of content about it and lots of companies are using it and communicate about it. We can do CQRS without even knowing we do!
It does not imply working with microservices, or a messaging infrastructure, or Events, or doing DDD in essence. It’s just often used with those techniques for reasons.
When should we use CQRS Pattern !
In following scenarios we can use CQRS Pattern.
- It is perfect in case of a large difference between the number of reads and writes from a system (social networks being examples of such system). You can scale independently both sides e.g. you can assign more resources to read services.
- If you want to parallelize the development and use two teams. One team could be assigned to read the model and second one to the write side. Please note, however, that both teams have to be deeply familiar with the CQRS pattern.
- Multiple services compete to alter the same resources.
- It might be possible where one team of developers can focus on the complex domain model that is part of the write model, and another team can focus on the read model and the user interfaces.
One Write Model, N Read Models –
The idea revolve around CQRS is to enable an application (in the large sense) to work a number of models.
- There’s only one and only one internal model it writes with, which is altered by commands.
- There might be one or several read models it and other applications read from (it just because we can’t let others read the write model).
Although, it doesn’t matter even if Read Models can be read by front-ends or by APIs.
Conclusion –
In this blog we have learnt all about the traditional architecture, principles. Then, we discussed the CQRS to overcome the problems being faced with the traditional model. Read models vs Write model, how to use and why we use it.
