Backend interview prep

Start

CQRS (Command Query Responsibility Segregation) Interview Questions and Answers

Learn CQRS with interview questions, Mermaid diagrams, Spring Boot examples, Kafka integration, Event Sourcing relationship, and enterprise production best practices.

CQRS (Command Query Responsibility Segregation) - Interview Questions & Answers

Most traditional applications use the same database and same model for both reading and writing data.

As systems grow, read traffic and write traffic have different requirements.

For example:

  • Millions of users may search products.
  • Thousands of users place orders.
  • Only a few administrators update product details.

Using a single model for both operations becomes difficult to scale.

CQRS (Command Query Responsibility Segregation) solves this problem by separating the Write Model (Commands) from the Read Model (Queries).

CQRS is widely used in:

  • Banking
  • E-Commerce
  • Trading Platforms
  • Inventory Systems
  • Order Management
  • High-Traffic Microservices

CQRS Architecture

flowchart LR

Client --> CommandApi["Command API"]

Client --> QueryApi["Query API"]

CommandApi["Command API"] --> WriteDatabase["Write Database"]

WriteDatabase["Write Database"] --> Kafka

Kafka --> ProjectionService["Projection Service"]

ProjectionService["Projection Service"] --> ReadDatabase["Read Database"]

ReadDatabase["Read Database"] --> QueryApi["Query API"]

Q1. What is CQRS?

Answer

CQRS stands for Command Query Responsibility Segregation.

It separates:

  • Commands (Write Operations)
  • Queries (Read Operations)

Instead of using one model for everything, CQRS uses different models optimized for reading and writing.

Basic Flow

flowchart TD

Commands --> WriteModel["Write Model"]

Queries --> ReadModel["Read Model"]

Benefits

  • Independent Scaling
  • Better Performance
  • Simplified Models
  • Improved Maintainability

Q2. Why do we need CQRS?

Answer

In many enterprise systems:

  • Reads greatly outnumber writes.
  • Read and write workloads are different.
  • Reporting queries are expensive.

CQRS allows each side to be optimized independently.

Traditional CRUD

flowchart LR

Application --> SingleDatabase["Single Database"]

SingleDatabase["Single Database"] --> Read

SingleDatabase["Single Database"] --> Write

CQRS

flowchart LR

Application --> WriteDatabase["Write Database"]

Application --> ReadDatabase["Read Database"]

Q3. What is the difference between Commands and Queries?

Answer

A Command changes system state.

Examples:

  • Create Order
  • Update Customer
  • Process Payment

A Query retrieves data without modifying it.

Examples:

  • Get Order
  • Search Customer
  • View Transaction History

Comparison

Command Query
Updates data Reads data
Changes state No state change
Validation required Optimized for speed
Business logic Read-only

Commands vs Queries

flowchart TD

Command --> WriteDatabase["Write Database"]

Query --> ReadDatabase["Read Database"]

Q4. What are the components of CQRS?

Answer

A CQRS architecture commonly includes:

  • Command API
  • Command Handler
  • Write Database
  • Event Broker
  • Projection Service
  • Read Database
  • Query API

Components

mindmap
  root((CQRS))
    Commands
    Write Model
    Event Broker
    Projection
    Read Model
    Queries

Q5. How does CQRS work?

Answer

Typical workflow:

  1. Client sends a command.
  2. Write model validates the request.
  3. Database is updated.
  4. Event is published.
  5. Projection updates the read model.
  6. Clients query the read database.

Workflow

sequenceDiagram
participant Client
participant Command
participant WriteDB
participant Kafka
participant ReadDB
Client->>Command: Create Order
Command->>WriteDB: Save Order
WriteDB-->>Kafka: OrderCreated Event
Kafka-->>ReadDB: Update Projection
Client->>ReadDB: Get Order

Q6. What is the relationship between CQRS and Event Sourcing?

Answer

CQRS and Event Sourcing are different patterns.

They are often used together but are independent.

CQRS:

  • Separates reads and writes.

Event Sourcing:

  • Stores every event.

Together

flowchart LR

Command --> EventStore["Event Store"]

EventStore["Event Store"] --> Kafka

Kafka --> Projection

Projection --> ReadDatabase["Read Database"]

Interview Tip

CQRS does not require Event Sourcing.

Event Sourcing naturally complements CQRS.

Q7. How does Spring Boot implement CQRS?

Answer

Spring Boot commonly uses:

  • REST Controllers
  • Command Services
  • Query Services
  • Spring Kafka
  • JPA
  • Projection Services

Spring Boot Architecture

flowchart TD

RestApi["REST API"] --> CommandService["Command Service"]

CommandService["Command Service"] --> WriteDatabase["Write Database"]

WriteDatabase["Write Database"] --> Kafka

Kafka --> ProjectionService["Projection Service"]

ProjectionService["Projection Service"] --> ReadDatabase["Read Database"]

ReadDatabase["Read Database"] --> QueryService["Query Service"]

Benefits

  • Clean separation
  • Better scalability
  • Independent deployments

Q8. What are common CQRS implementation mistakes?

Answer

Common mistakes include:

  • Using CQRS for simple CRUD systems
  • Ignoring eventual consistency
  • Sharing the same model
  • No event versioning
  • Missing replay capability
  • Tight coupling
  • No monitoring

Wrong Design

Single Database

↓

Everything ❌

Correct Design

Write Model

↓

Events

↓

Read Model ✅

Q9. What are the advantages and disadvantages of CQRS?

Answer

Advantages

  • Better scalability
  • Faster queries
  • Independent optimization
  • Flexible data models
  • Event-driven integration

Challenges

  • Eventual consistency
  • Higher complexity
  • More infrastructure
  • Monitoring complexity
  • Projection management

Pros & Cons

mindmap
  root((CQRS))
    Advantages
      Scaling
      Performance
      Flexibility
    Challenges
      Complexity
      Consistency
      Monitoring

Q10. What are the enterprise best practices for CQRS?

Answer

Follow these recommendations:

  • Use CQRS only for complex domains.
  • Keep command validation strict.
  • Optimize read models independently.
  • Use asynchronous projections.
  • Version events.
  • Build replay mechanisms.
  • Monitor projections.
  • Secure both APIs separately.
  • Use idempotent consumers.
  • Plan for eventual consistency.

Enterprise CQRS Architecture

flowchart TD

Client --> CommandApi["Command API"]

CommandApi["Command API"] --> WriteDatabase["Write Database"]

WriteDatabase["Write Database"] --> Kafka

Kafka --> ProjectionService["Projection Service"]

ProjectionService["Projection Service"] --> ReadDatabase["Read Database"]

ReadDatabase["Read Database"] --> QueryApi["Query API"]

QueryApi["Query API"] --> Client

CQRS Processing Pipeline

flowchart LR

Command --> WriteModel["Write Model"]
WriteModel["Write Model"] --> Event
Event --> Projection
Projection --> ReadModel["Read Model"]
ReadModel["Read Model"] --> Query

CQRS Overview

mindmap
  root((CQRS))
    Command API
    Write Database
    Kafka
    Projection
    Read Database
    Query API
    Eventual Consistency
    Scaling

Traditional CRUD vs CQRS

Traditional CRUD CQRS
Single model Separate read/write models
One database Multiple optimized databases
Limited scalability Independent scaling
Simple architecture Higher complexity
Immediate consistency Eventual consistency
Good for small systems Good for large systems

Real-World Banking Example

A banking application handles account transactions.

Write Flow

Customer Transfers Money

↓

Transfer Command

↓

Write Database

↓

TransferCompleted Event

Read Flow

TransferCompleted Event

↓

Projection Service

↓

Read Database

↓

Customer Views Transaction History

The write database focuses on transactional integrity, while the read database is optimized for fast balance and transaction history queries.

Senior Interview Tip

CQRS is most valuable in systems with heavy read traffic, complex business rules, and independent scaling requirements.

A production-ready CQRS architecture typically includes:

  • Spring Boot
  • Apache Kafka
  • Command API
  • Query API
  • Write Database
  • Read Database
  • Projection Services
  • Event Sourcing (optional)
  • Schema Registry
  • Dead Letter Queues
  • Replay Services
  • Idempotent Consumers
  • Prometheus & Grafana
  • Distributed Tracing
  • Audit Logging

Remember:

  • Commands modify data.
  • Queries retrieve data.
  • Write and Read models evolve independently.
  • CQRS improves scalability at the cost of additional architectural complexity.

Quick Revision

  • CQRS separates command (write) and query (read) responsibilities.
  • Commands change system state; queries do not.
  • Use separate models and databases when beneficial.
  • Publish events after successful writes.
  • Update read models through asynchronous projections.
  • CQRS can be used with or without Event Sourcing.
  • Accept eventual consistency between write and read models.
  • Monitor projection lag and replay capabilities.
  • Build idempotent consumers for event processing.
  • Combine CQRS, Kafka, projections, monitoring, and replay for enterprise-grade event-driven systems.