CQRS Architecture (2024)

In this tutorial, we will look at how CQRS (Command Query Responsibility Segregation) works and its components. It's also utilised in many microservices as a suitable design pattern to follow when you have to operate or separate read and write operations.

What is CQRS?
Ans:

CQRS (Command Query Responsibility Segregation) is a microservices design pattern that divides reading and writing into two models. Every method should be either a Command that performs an action or a Query that returns data. CQRS divides reads and writes into independent models, updating data with commands and reading data with queries.

Why to use CQRS?
Ans:

The same data model is used to query and update a database in traditional designs. That's straightforward and effective for basic CRUD operations. However, in increasingly complicated applications, this strategy might become difficult. We can use CQRS to optimize the read and write sides individually. Also for applications with a large number of users or that require a large number of parallel operations on the same batch of data. It's a lot easier to figure out what a user wants and then translate that into domain events.

We might get data conflict doing operations (read, write) parallelly on same data.

Performance may impact due to the burden on the data store and data access layer for complexity of queries necessary and to extract information.

Security and permissions can become complicated, as each entity is exposed to both read and write activities, which may disclose data in the improper context.

What are the benefits of CQRS?
Ans:

1. Scaling that is self-contained. CQRS allows read and write workloads to scale separately, potentially reducing lock contention.
2. Data schemas that have been optimized. On the read side, a schema optimized for queries can be used, while on the write side, a schema designed for updates can be used.
3. It's considerably easier to ensure that only the relevant domain entities are writing to the data in terms of security.
4. Concerns are separated. Separating the read and write sides can lead to more maintainable and flexible architectures. The write model contains the majority of the complicated business logic. The read model might be rather straightforward.
5. Queries that are simpler. When querying, the application can avoid complex joins by saving a materialized view in the read database.

When should the CQRS pattern be used?
Ans:

1. To reduce the number of merge conflicts.
2. Situations in which one team of developers focuses on the write model's difficult domain model, while another focuses on the read model and user interfaces.
3. Instances in which data read performance must be fine-tuned separately from data write performance, especially when the number of reads is significantly more than the number of writes.

This solution isn't recommended when the domain or business rules are basic, and simple CRUD-style user interface and data access operations are enough.

What is Event Source in Microservices?
Ans:

Event Sourcing is a method of storing an immutable series of events in order to persist application state into event store. As a result of these events, state updates are triggered to update the application state. The aggregate of events can always be used to establish the present state of an application.