Separates Read Operations from the Transactional Operations using separate Interfaces. This Pattern maximizes performance, scalability and security.

What’s wrong with traditional data management system?

In traditional data management systems both the queries and commands are executed against the same set of entities in a single data repository. Meaning, all the CRUD operations are applied to the same representation of the entity.

Disadvantages:

  • Unwanted columns in the request payload even when they are not required to update the database. Also, managing Security and Permissions becomes complex.
  • Risk of deadlocks, conflicts on the parallel sets of operations. Eventually leads to performance issues.

Solve using CQRS Pattern:

CQRS Pattern segregates the read and write operations such as queries and commands. Unlike CRUD designs CQRS pattern is not feasible for scaffolding mechanisms.

The read store can be a read-only replica of the write store, or the read and write stores can have a different structure altogether. Using multiple read-only replicas of the read store can greatly increase query performance and application UI responsiveness, especially in distributed scenarios where read-only replicas are located close to the application instances. Some database systems (SQL Server) provide additional features such as failover replicas to maximize availability.

Separation of the read and write stores also allows each to be scaled appropriately to match the load. For example, read stores typically encounter a much higher load than write stores.

Note: Consider applying CQRS to limited sections of your system where it will be most valuable.

When to use CQRS?

  • When you have multiple operations to perform in parallel.
  • Task based user interfaces over a complex domain models.
  • When familiar with DDD (Domain Driven Design).
  • Read model has no validation, unless returning a DTO.
  • When require high performance read and write data applications with multiple parallel sets of operations.
  • Suitable for Product development, which evolves over a period of time and might contain multiple versions of models or business rules change regularly.
  • Integration Systems, when typically handling failure in sub systems. Additionally, considering integrating with middleware like Service bus for messaging helps the situations.
  • When the development team understands the concept that the requirements has a clear path of domain and business rules.