Bird
Raised Fist0
HLDsystem_design~20 mins

CQRS (Command Query Responsibility Segregation) in HLD - Practice Problems & Coding Challenges

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Challenge - 5 Problems
🎖️
CQRS Mastery
Get all challenges correct to earn this badge!
Test your skills under time pressure!
🧠 Conceptual
intermediate
2:00remaining
Understanding the core principle of CQRS

Which statement best describes the main idea behind CQRS?

ACombining command and query operations into one service to reduce latency.
BUsing a single database for both reading and writing to simplify data management.
CSeparating the system into two parts: one for handling commands (writes) and another for handling queries (reads).
DStoring all data in a cache to speed up both reads and writes.
Attempts:
2 left
💡 Hint

Think about how CQRS splits responsibilities to improve scalability and clarity.

Architecture
intermediate
2:00remaining
Identifying components in a CQRS architecture

In a typical CQRS system, which component is responsible for updating the data store after receiving a command?

ACommand Handler
BEvent Publisher
CRead Repository
DQuery Model
Attempts:
2 left
💡 Hint

Consider which part processes write requests and changes the data.

scaling
advanced
2:00remaining
Scaling reads and writes in CQRS

Which approach best explains how CQRS helps scale read and write workloads independently?

ABy using separate databases for reads and writes, allowing each to be optimized and scaled based on its workload.
BBy merging read and write operations into a single database to reduce complexity.
CBy caching all writes and delaying reads to reduce load on the database.
DBy replicating the write database multiple times without separating reads.
Attempts:
2 left
💡 Hint

Think about how separating responsibilities affects scaling.

tradeoff
advanced
2:00remaining
Tradeoffs of using CQRS

What is a common tradeoff when implementing CQRS in a system?

AElimination of the need for event-driven communication.
BReduced performance because reads and writes are combined into one model.
CSimplified data management by using a single database for all operations.
DIncreased complexity due to managing separate models and eventual consistency challenges.
Attempts:
2 left
💡 Hint

Consider what extra work CQRS introduces beyond simple CRUD.

estimation
expert
2:00remaining
Estimating capacity for a CQRS system

A CQRS system handles 10,000 write commands per second and 100,000 read queries per second. If the write database can handle 15,000 writes per second and the read database can handle 120,000 reads per second, what is the maximum sustainable throughput for the system?

A15,000 writes and 120,000 reads per second
B10,000 writes and 100,000 reads per second
C10,000 writes and 120,000 reads per second
D15,000 writes and 100,000 reads per second
Attempts:
2 left
💡 Hint

The system throughput is limited by the component with the lowest capacity for each operation.

Practice

(1/5)
1. What is the main purpose of using CQRS in system design?
easy
A. To encrypt data for security purposes
B. To combine all database operations into a single service
C. To separate read and write operations for better scalability
D. To reduce the number of servers needed

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 part to be optimized and scaled independently, improving performance and maintainability.
  3. Final Answer:

    To separate read and write operations for better scalability -> Option C
  4. Quick Check:

    CQRS = Separate reads and writes [OK]
Hint: CQRS splits commands and queries for scaling [OK]
Common Mistakes:
  • Thinking CQRS combines operations into one service
  • Confusing CQRS with security encryption
  • Assuming CQRS reduces server count directly
2. Which of the following is the correct way to describe the role of the 'Command' in CQRS?
easy
A. It processes write operations that change system state
B. It handles read-only queries to fetch data
C. It stores cached data for faster access
D. It manages user authentication and authorization

Solution

  1. Step 1: Define Command role in CQRS

    Commands are responsible for write operations that modify the system's state.
  2. Step 2: Differentiate from Query

    Queries only read data without changing it, so they are not commands.
  3. Final Answer:

    It processes write operations that change system state -> Option A
  4. Quick Check:

    Command = Write operations [OK]
Hint: Commands change data; queries only read [OK]
Common Mistakes:
  • Confusing commands with queries
  • Thinking commands handle caching
  • Assuming commands manage security
3. Consider a system using CQRS where the write side updates a user profile and the read side serves user data. If the write side updates the user's email, what is the expected behavior on the read side immediately after the update?
medium
A. The read side instantly shows the updated email without delay
B. The read side deletes the user data until refreshed
C. The read side rejects the query until the write completes
D. The read side may show the old email briefly due to asynchronous update

Solution

  1. Step 1: Understand asynchronous update in CQRS

    In CQRS, the read side is often updated asynchronously via events after the write completes.
  2. Step 2: Identify read side behavior after write

    Because of this delay, the read side may temporarily show stale data until it receives the update event.
  3. Final Answer:

    The read side may show the old email briefly due to asynchronous update -> Option D
  4. Quick Check:

    Read side updates asynchronously = possible stale data [OK]
Hint: Reads update asynchronously, so data may lag briefly [OK]
Common Mistakes:
  • Assuming immediate read consistency
  • Thinking reads block until writes finish
  • Believing read data is deleted during update
4. A developer implemented CQRS but notices that the read model is not updating after commands execute. What is the most likely cause?
medium
A. The read model database is corrupted and cannot be read
B. The command handler is not sending events to update the read model
C. The query side is trying to write data instead of reading
D. The system is using synchronous updates causing deadlocks

Solution

  1. Step 1: Identify how read model updates in CQRS

    The read model updates via events sent by the command handler after state changes.
  2. Step 2: Diagnose missing updates

    If the read model is not updating, likely the events are not being sent or processed properly.
  3. Final Answer:

    The command handler is not sending events to update the read model -> Option B
  4. Quick Check:

    Missing events cause read model stale data [OK]
Hint: Check if events are sent after commands [OK]
Common Mistakes:
  • Blaming database corruption without evidence
  • Confusing query side roles
  • Assuming synchronous updates cause deadlocks here
5. You are designing a high-traffic e-commerce system using CQRS. Which approach best ensures that the read side remains highly available and scalable while keeping data reasonably fresh?
hard
A. Use event sourcing to asynchronously update read models and deploy multiple read replicas
B. Use a single database for both reads and writes to avoid data duplication
C. Synchronously update the read model within the command transaction to ensure consistency
D. Disable caching on the read side to always fetch fresh data from the write database

Solution

  1. Step 1: Understand scalability needs in CQRS

    Separating reads and writes allows scaling read replicas independently to handle high traffic.
  2. Step 2: Use event sourcing for asynchronous updates

    Event sourcing helps keep read models updated asynchronously, balancing freshness and availability.
  3. Step 3: Evaluate other options

    Single database limits scalability; synchronous updates reduce availability; disabling caching hurts performance.
  4. Final Answer:

    Use event sourcing to asynchronously update read models and deploy multiple read replicas -> Option A
  5. Quick Check:

    Event sourcing + read replicas = scalable, fresh reads [OK]
Hint: Event sourcing + replicas = scalable reads with freshness [OK]
Common Mistakes:
  • Using single DB limits scalability
  • Synchronous updates reduce availability
  • Disabling cache hurts performance