CQRS pattern in Microservices - System Design Exercise

Design: CQRS-based Microservices System

Design the architecture for a microservices system using CQRS pattern including components, data flow, and database schema. Out of scope: detailed UI design, deployment automation.

Functional Requirements

FR1: Separate read and write operations for better scalability and performance

FR2: Support eventual consistency between read and write data stores

FR3: Handle 10,000 concurrent users with low latency

FR4: Provide APIs for clients to query data and submit commands

FR5: Ensure data integrity and fault tolerance

Non-Functional Requirements

NFR1: Read API latency p99 < 150ms

NFR2: Write API latency p99 < 300ms

NFR3: System availability 99.9% uptime

NFR4: Data consistency eventual but within 5 seconds

NFR5: Microservices communicate asynchronously where possible

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Command service (write model)

Query service (read model)

Event store or message broker

Separate databases for read and write models

API gateway or client-facing API layer

Design Patterns

Event sourcing

Asynchronous messaging

Eventual consistency

Microservices communication patterns

Database per service

Reference Architecture

Client
  |
  v
API Gateway
  |
  +---------------------+---------------------+
  |                                           |
Command Service (Write Model)           Query Service (Read Model)
  |                                           |
Write Database                             Read Database
  |                                           |
  +-------------------+-----------------------+
                      |
                Event Bus / Message Broker
                      |
            Event Handlers / Projections

Components

API Gateway

Nginx or Kong

Routes client requests to command or query services

Command Service

Spring Boot / Node.js microservice

Handles write operations and business logic

Write Database

PostgreSQL or MongoDB

Stores authoritative write data

Event Bus / Message Broker

Kafka or RabbitMQ

Asynchronously transports events from command to query services

Query Service

Spring Boot / Node.js microservice

Handles read operations optimized for queries

Read Database

Elasticsearch or Redis

Stores denormalized data optimized for fast reads

Event Handlers / Projections

Microservices or serverless functions

Consume events and update read database

Request Flow

1. Client sends a command (write request) to API Gateway

2. API Gateway routes command to Command Service

3. Command Service validates and processes command, updates Write Database

4. Command Service publishes event to Event Bus

5. Event Handlers consume event from Event Bus

6. Event Handlers update Read Database with denormalized data

7. Client sends query (read request) to API Gateway

8. API Gateway routes query to Query Service

9. Query Service reads data from Read Database and returns response

Database Schema

Entities: Command Database stores normalized domain entities with transactional integrity. Read Database stores denormalized views optimized for queries. Relationship: Event Handlers project changes from Command Database events into Read Database views. Example: Order entity in Command DB, OrderSummary view in Read DB.

Scaling Discussion

Bottlenecks

Command Service write throughput limits

Event Bus message volume and latency

Read Database query performance under high load

Eventual consistency delay causing stale reads

Single point of failure in API Gateway

Solutions

Scale Command Service horizontally with load balancer

Partition Event Bus topics and use consumer groups for parallelism

Use caching and read replicas for Read Database

Tune event processing and monitor lag to reduce consistency delay

Deploy multiple API Gateway instances with health checks

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for architecture and data flow, 10 minutes for scaling and trade-offs, 10 minutes for Q&A

Explain why separating reads and writes improves scalability

Discuss eventual consistency trade-offs and how to handle them

Describe asynchronous communication via event bus

Highlight how read and write databases differ in design

Mention scaling strategies and fault tolerance