System Design: Command and Query Responsibility Segregation (CQRS)

Command Query Responsibility Segregation (CQRS) is an architectural pattern that divides a system's actions into commands and queries. It was first described by Greg Young.

In CQRS, a command is an instruction, a directive to perform a specific task. It is an intention to change something and doesn't return a value, only an indication of success or failure. And, a query is a request for information that doesn't change the system's state or cause any side effects.

The core principle of CQRS is the separation of commands and queries. They perform fundamentally different roles within a system, and separating them means that each can be optimized as needed, which distributed systems can really benefit from.

CQRS with Event Sourcing

The CQRS pattern is often used along with the Event Sourcing pattern. CQRS-based systems use separate read and write data models, each tailored to relevant tasks and often located in physically separate stores.

When used with the Event Sourcing pattern, the store of events is the write model and is the official source of information. The read model of a CQRS-based system provides materialized views of the data, typically as highly denormalized views.

Advantages

Let's discuss some advantages of CQRS:

• Allows independent scaling of read and write workloads.
• Easier scaling, optimizations, and architectural changes.
• Closer to business logic with loose coupling.
• The application can avoid complex joins when querying.
• Clear boundaries between the system behavior.

Disadvantages

Below are some disadvantages of CQRS:

• More complex application design.
• Message failures or duplicate messages can occur.
• Dealing with eventual consistency is a challenge.
• Increased system maintenance efforts.

Use cases

Here are some scenarios where CQRS will be helpful:

• The performance of data reads must be fine-tuned separately from the performance of data writes.
• The system is expected to evolve over time and might contain multiple versions of the model, or where business rules change regularly.
• Integration with other systems, especially in combination with event sourcing, where the temporal failure of one subsystem shouldn't affect the availability of the others.
• Better security to ensure that only the right domain entities are performing writes on the data.

---

This article is part of my open source System Design Course available on Github.

karanpratapsingh / system-design

Learn how to design systems at scale and prepare for system design interviews

System Design

Hey, welcome to the course. I hope this course provides a great learning experience.

This course is also available on my website and as an ebook on leanpub. Please leave a ⭐ as motivation if this was helpful!

Table of contents

• Getting Started

  • What is system design?

• Chapter I

  • IP
  • OSI Model
  • TCP and UDP
  • Domain Name System (DNS)
  • Load Balancing
  • Clustering
  • Caching
  • Content Delivery Network (CDN)
  • Proxy
  • Availability
  • Scalability
  • Storage

• Chapter II

  • Databases and DBMS
  • SQL databases
  • NoSQL databases
  • SQL vs NoSQL databases
  • Database Replication
  • Indexes
  • Normalization and Denormalization
  • ACID and BASE consistency models
  • CAP theorem
  • PACELC Theorem
  • Transactions
  • Distributed Transactions
  • Sharding
  • Consistent Hashing
  • Database Federation

• Chapter III

  • N-tier architecture
  • Message Brokers
  • Message Queues
  • Publish-Subscribe
  • Enterprise Service Bus (ESB)
  • Monoliths and Microservices
  • Event-Driven Architecture (EDA)
  • Event Sourcing
  • Command and Query Responsibility Segregation (CQRS)
  • API Gateway
  • REST, GraphQL, gRPC
  • Long polling, WebSockets, Server-Sent Events (SSE)

• Chapter IV

  • …

View on GitHub