Command Query Responsibility Segregation (CQRS)

Introduction: The Restaurant Kitchen Problem

Imagine a busy restaurant.

The restaurant handles two types of activities:

1. Taking orders
2. Serving food information to customers

These two operations are very different.

Now imagine the restaurant uses one single system for both tasks.

When thousands of customers start asking for the menu while others place orders:

• Kitchen system slows down
• Orders take longer
• Menu queries block order processing

This is similar to how many traditional applications work.

Both reads and writes share the same database and model.

But in real systems:

• Reads are far more frequent than writes
• Reads and writes have different scalability needs

To solve this problem, we use a design pattern called CQRS.

What is CQRS?

Command Query Responsibility Segregation (CQRS) is a design pattern where:

Read operations and write operations are separated into different models or services.

Instead of using one model for everything, CQRS splits the system into:

So instead of:

Application → Single Model → Database

We do:

Commands → Write Model → Write Database
Queries → Read Model → Read Database

Core Principle

CQRS is based on a simple rule:

Commands change state. Queries return state.

A command must not return data.

A query must not change state.

Example

Suppose we have an E-commerce system.

Commands

These modify system state.

CreateOrder
UpdateOrderStatus
CancelOrder
AddItemToCart

Queries

These only fetch data.

GetOrderDetails
GetUserCart
GetOrderHistory
GetProductList

Separating these operations improves performance and scalability.

Traditional CRUD Architecture

Most systems use CRUD architecture.

Both reads and writes hit the same database.

Problems:

CQRS Architecture

CQRS separates read and write paths.

Now reads and writes operate independently.

Command Side (Write Model)

The command side handles:

• Business logic
• State changes
• Data validation
• Transactions

Example command:

PlaceOrder

Flow:

Characteristics:

Query Side (Read Model)

The query side is optimized for fast data retrieval.

Example query:

GetOrderSummary

Flow:

Characteristics:

Why Separate Read and Write Models?

Because their requirements are different.

Example:

Write model:

Orders
Users
Products

Read model:

UserOrderHistoryView
ProductPopularityView
DashboardMetricsView

Read models can be optimized for specific queries.

Synchronizing Read and Write Models

Since read and write models are separate, we need a way to keep them synchronized.

Common approaches:

Event-Based CQRS

Most CQRS systems use events.

Example:

OrderPlaced
OrderCancelled
PaymentCompleted

Architecture:

Process:

1. Command modifies write DB
2. Event published
3. Read model updated asynchronously

Eventual Consistency

Since updates happen asynchronously:

Read models may lag slightly behind writes.

Example:

User places order.

Write DB updated instantly
Read DB updated after 100 ms

This is called:

Eventual Consistency

Most modern systems accept this tradeoff.

CQRS with Event Sourcing

CQRS is often combined with Event Sourcing.

Instead of storing current state:

We store all events that occurred.

Example event log:

OrderCreated
ItemAdded
PaymentCompleted
OrderShipped

Current state is reconstructed from events.

Architecture:

Benefits:

Read Model Optimization

Read databases can be optimized differently.

Examples:

Example:

Each optimized for specific queries.

Scaling CQRS

CQRS scales extremely well.

Write Scaling

Sharded write database

Read Scaling

Multiple read replicas

Architecture:

Reads can scale horizontally.

Real-World Example: E-Commerce

In a large e-commerce platform:

Daily traffic:

Reads → 1 billion
Writes → 10 million

Ratio:

100:1

If reads and writes share one database:

System becomes slow.

CQRS allows:

• Write DB optimized for transactions
• Read DB optimized for queries

CQRS in Microservices

CQRS works extremely well with microservices.

Example architecture:

Services emit events.

Read models consume them.

Advantages of CQRS

Challenges of CQRS

CQRS is powerful but not suitable for every system.

When to Use CQRS

Use CQRS when:

When NOT to Use CQRS

Avoid CQRS if:

Real-World Systems Using CQRS

Large tech companies use CQRS patterns.

Examples:

These systems process millions of events per second.

CQRS vs Traditional Architecture

Interview Questions

What is CQRS?

A design pattern that separates read operations (queries) from write operations (commands).

Why use CQRS?

To:

• Improve scalability
• Optimize read performance
• Handle complex domains

What is Eventual Consistency?

When read models update asynchronously after writes.

How does CQRS scale?

Reads and writes scale independently using different databases and services.

Key Takeaways

Final Analogy

Think of CQRS like a library system.

Writing books

Authors update books.

Write Model

Reading books

Millions of readers access copies.

Read Model

Instead of giving readers the original manuscript, libraries distribute optimized copies.

This allows millions of readers without slowing down the authors.

Conclusion

Command Query Responsibility Segregation is one of the most powerful patterns in High Level Design and distributed systems.

It allows systems to:

• Scale reads independently
• Handle massive workloads
• Optimize data access patterns
• Integrate seamlessly with event-driven architectures

However, CQRS introduces complexity and should be used when the benefits outweigh the cost.

In large-scale systems handling millions of requests per second, CQRS becomes an essential architectural tool.