CQRS pattern in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding CQRS Command and Query Separation

In the CQRS pattern, what is the primary reason for separating commands and queries into different models?

A To optimize read and write operations independently for better performance and scalability

B To ensure all data is stored in a single database for consistency

C To combine read and write logic into one service for simplicity

D To avoid using any caching mechanisms in the system

💡 Hint

Think about how separating responsibilities can help improve system efficiency.

CQRS separates commands (writes) and queries (reads) so each can be optimized independently, improving performance and scalability.

❓ Architecture

intermediate

CQRS Architecture Components

Which component in a CQRS architecture is responsible for handling commands and updating the write database?

A Read Model

B Query Handler

C Command Handler

D Event Store

💡 Hint

Commands change data, so which component processes these changes?

The Command Handler processes commands and updates the write database or triggers events.

❓ scaling

advanced

Scaling CQRS Read and Write Models

In a high-traffic system using CQRS, which scaling strategy best improves read performance without affecting write throughput?

A Disable asynchronous event propagation to speed up writes

B Scale out the read model by adding more read replicas and caching layers

C Use a single database for both reads and writes to reduce complexity

D Scale out the write model by adding more command handlers

💡 Hint

Think about how to handle many read requests efficiently without slowing down writes.

Scaling out the read model with replicas and caching improves read performance independently, keeping writes unaffected.

❓ tradeoff

advanced

Tradeoffs of Eventual Consistency in CQRS

What is a common tradeoff when using eventual consistency between the write and read models in CQRS?

A Read data may be temporarily stale, causing slight delays in reflecting recent writes

B Write operations become slower due to synchronous updates to the read model

C The system loses the ability to scale reads independently

D Commands and queries must be handled by the same service

💡 Hint

Consider what happens when updates take time to appear in the read model.

Eventual consistency means the read model updates asynchronously, so reads might show old data briefly.

❓ estimation

expert

Estimating Capacity for CQRS Read Model

A CQRS system handles 10,000 write commands per minute and 96,000 read queries per minute. If each read query requires 5ms processing time on average, how many read replicas are needed to handle the load with 80% CPU utilization per replica?

A At least 7 replicas

B At least 12 replicas

C At least 15 replicas

D At least 10 replicas

💡 Hint

Calculate total processing time per minute and divide by capacity per replica.

Total read processing time per minute = 96,000 * 5 ms = 480,000 ms = 480 seconds. Each replica can process 60 * 0.8 = 48 seconds of CPU time per minute. Number of replicas = 480 / 48 = 10.

Practice

1. What is the main purpose of the CQRS pattern in microservices architecture?

easy

A. To separate read and write operations for better scalability

B. To combine all database operations into a single service

C. To encrypt data during transmission between services

D. To cache all data on the client side for faster access

Solution

1. Step 1: Understand CQRS concept

   CQRS stands for Command Query Responsibility Segregation, which means separating commands (writes) from queries (reads).

2. Step 2: Identify the main benefit

   This separation allows each side to be optimized and scaled independently, improving performance and maintainability.

3. Final Answer:

   To separate read and write operations for better scalability -> Option A

4. Quick Check:

   CQRS = Separate reads and writes [OK]

Hint: CQRS splits commands and queries separately [OK]

Common Mistakes:

• Thinking CQRS merges all operations into one service
• Confusing CQRS with encryption or caching
• Assuming CQRS only applies to database encryption

2. Which of the following is the correct way to describe the command side in CQRS?

easy

A. Handles read-only queries to fetch data

B. Manages user authentication and sessions

C. Processes write operations that change state

D. Caches data for faster retrieval

Solution

1. Step 1: Define command side role

   The command side in CQRS is responsible for handling commands, which are operations that change the system's state (writes).

2. Step 2: Eliminate incorrect options

   Read-only queries belong to the query side, caching is a separate concern, and authentication is unrelated to CQRS commands.

3. Final Answer:

   Processes write operations that change state -> Option C

4. Quick Check:

   Command side = writes [OK]

Hint: Commands change data, queries read data [OK]

Common Mistakes:

• Confusing command side with query side
• Thinking command side handles caching
• Mixing authentication with CQRS commands

3. Given the following simplified CQRS flow:

1. User sends a command to update an order.
2. Command handler updates the write database.
3. An event is published.
4. The read model updates asynchronously.
What is the main reason for step 4?

medium

A. To validate the command before processing

B. To keep the read database in sync with the write database

C. To rollback the write operation if needed

D. To encrypt the data before sending to the client

Solution

1. Step 1: Understand event role in CQRS

   After the write database updates, an event signals that data changed.

2. Step 2: Purpose of read model update

   The read model updates asynchronously to reflect the latest data for queries, keeping it consistent with writes.

3. Final Answer:

   To keep the read database in sync with the write database -> Option B

4. Quick Check:

   Event updates read model = sync reads [OK]

Hint: Events update read model after writes [OK]

Common Mistakes:

• Thinking event validates or rolls back commands
• Confusing encryption with event handling
• Assuming read model updates happen synchronously

4. In a CQRS system, a developer notices that the read model sometimes shows stale data after a write. What is the most likely cause?

medium

A. The client is caching old data aggressively

B. The command handler failed to update the write database

C. The write database is not replicated properly

D. The event to update the read model is delayed or lost

Solution

1. Step 1: Identify cause of stale read data

   In CQRS, the read model updates asynchronously via events. If events are delayed or lost, the read model lags behind.

2. Step 2: Rule out other causes

   If the write database failed, writes wouldn't succeed. Client caching or replication issues are less likely to cause this specific CQRS symptom.

3. Final Answer:

   The event to update the read model is delayed or lost -> Option D

4. Quick Check:

   Stale reads = delayed event update [OK]

Hint: Stale reads usually mean event delay or loss [OK]

Common Mistakes:

• Blaming write database failure without evidence
• Ignoring event delivery reliability
• Assuming client caching is always the cause

5. You are designing a high-traffic e-commerce system using CQRS. Which approach best handles the challenge of scaling the read side independently from the write side?

hard

A. Use separate databases for read and write models with event-driven synchronization

B. Use a single database for both reads and writes with strong locking

C. Cache all writes on the client and batch update the database later

D. Directly query the write database for all read requests

Solution

1. Step 1: Understand scaling needs in CQRS

   Separating read and write databases allows independent scaling and optimization for each workload.

2. Step 2: Evaluate options for scaling reads

   Event-driven synchronization keeps the read database updated asynchronously, enabling fast, scalable queries without locking.

3. Step 3: Reject unsuitable options

   Single database with locking limits scalability; client caching risks data loss; querying write DB for reads causes contention.

4. Final Answer:

   Use separate databases for read and write models with event-driven synchronization -> Option A

5. Quick Check:

   Separate DBs + events = scalable CQRS [OK]

Hint: Separate read/write DBs with events scale best [OK]

Common Mistakes:

• Using one DB with locking reduces scalability
• Relying on client caching risks consistency
• Reading directly from write DB causes contention