CQRS is a very good tool when it comes to programming. It is really helpful and can make many things easier for you, keep reading and learn everything about CQRS.
What is CQRS?
CQRS is an architectural pattern, where the acronym stands for Command Query Responsibility Segregation. We can talk about CQRS when data read operations are separated from data write operations and occur on a different interface.
In most CQRS systems, read and write operations use different data models, sometimes even different data stores. This type of segregation makes it easier to scale, read and write operations, and control security, but adds additional complexity to your system.
Node.js at Scale, is a collection of articles that focus on the needs of companies with larger Node.js installations and advanced Node.
The level of segregation can vary in CQRS systems:
- Single data stores and separate model for reading and updating data.
- Separate data stores and separate model for reading and updating data.
In the simplest datastore separation, we can use read-only replicas to achieve segregation.
Why and when to use CQRS?
In a typical data management system, all CRUD operations (create delete read update) run on the same interface of entities in a single data store. How to create, update, query and delete table rows in a SQL database through the same model.
CQRS really shines compared to the traditional approach (using a single model) when building complex data models to validate, and meet your business logic when data manipulation occurs. Read operations versus update and write operations can be very different or much simpler, such as accessing only a subset of your data.
A very vivid example
In our Node.js monitoring tool, we use CQRS to segregate the storage and representation of the data. For example, when you view a Distributed Tracking visualization in our UI, the data behind it came in smaller chunks from our customers' application agents to our Public Collector API.
In the Collector API, we just do thin validation and send the data to a messaging queue for processing. At the other end of the queue, workers consume messages and resolve all necessary dependencies through other services. These workers are also saving the transformed data in the database.
If a problem occurs, we return the message with an exponential fallback and a maximum limit to our messaging queue. Compared to this complex data write flow, on the rendering side of the flow, we only query a read replica database and visualize the result for our clients.
CQRS and its event source
I have seen many times that people are confusing these two concepts. Both are widely used in event-driven infrastructures as well as event-driven micro-services, but they have very different meanings.
Report Database - Denormalizer
In some event-driven systems, CQRS is implemented so that the system contains one or more reporting databases.
A reporting database is a completely different read-only storage that models and preserves data in the best format to represent it. It's okay to store it in a de-standard format to optimize it for customer needs. In some cases, the reporting database contains only derived data, even from multiple data sources.
In a microservices architecture, we call a Denormalizer service if it listens for some events and maintains a database of reports based on them. The client is reading the reporting database from the denormalized service.
An example might be that the user profile service emits an event user.edit with useful information {id: 1, name: 'Mary Anne', Status: 'churn'}, Denormalizer service listens for it, but only stores it in its Reporting Database {name: 'Mary Anne'}, because the client is not interested in the internal churn state of the user.
It can be difficult to keep a reporting database in sync. Usually, we can only aim for eventual consistency.
Other
CQRS is a powerful architectural pattern to segregate read and write operations and their interfaces, but it also adds additional complexity to your system. In most cases, you shouldn't use CQRS for the whole system, only for specific parts where complexity and scalability make it necessary.
To read more about CQRS and reporting databases, I recommend checking out the following resources:
- CQRS - Martin Fowler
- CQRS - MSDN
- CQRS, Task Based UI, Event Source Again! - Greg Young
- CQRS and Event Source - Code on the Beach 2014 - Greg Young
- Reports Database - Martin Fowler
Congratulations on completing this lesson!
