Practice : CQRS (Command Query Responsibility Segregation)

Purpose and Strategic Importance

Command Query Responsibility Segregation (CQRS) is an architectural pattern that separates write operations (commands) from read operations (queries). By decoupling these responsibilities, systems can scale more efficiently, improve performance, and support specialised models for reading and writing data.

CQRS is particularly useful in systems with complex business rules, high throughput demands, or real-time analytics requirements. It enables flexibility, better control of side effects, and a natural fit with event-driven and microservices architectures.

Description of the Practice

  • Commands change application state (e.g. create order, cancel booking) and trigger domain logic.
  • Queries retrieve data without modifying it - optimised for different access patterns.
  • The write model enforces business rules and emits domain events.
  • The read model is denormalised and optimised for fast retrieval.
  • CQRS is often paired with Event Sourcing or asynchronous messaging systems.

How to Practise It (Playbook)

1. Getting Started

  • Identify use cases with distinct read and write concerns or scalability bottlenecks.
  • Model separate command and query flows - start with a clear separation in code.
  • Use synchronous commands and read replicas or projection tables for queries.
  • Implement validation, authorisation, and business logic in the command layer.

2. Scaling and Maturing

  • Move query models to separate infrastructure for performance and availability.
  • Use event-driven updates to sync projections (e.g. with Kafka, SQS, or outbox pattern).
  • Optimise query models independently of the write schema - support UX or analytics needs.
  • Track command outcomes with correlation IDs and observability tooling.
  • Use eventual consistency and idempotency controls where needed.

3. Team Behaviours to Encourage

  • Design write and read models with clear ownership and purpose.
  • Refactor toward CQRS incrementally - not everything needs separation.
  • Discuss trade-offs between consistency, latency, and complexity.
  • Document command and event flows for cross-team clarity.

4. Watch Out For…

  • Overengineering small or CRUD-based systems - CQRS adds complexity.
  • Poor observability across decoupled write and read paths.
  • Synchronisation issues without clear update and retry strategies.
  • Inconsistent read models if projections are not maintained reliably.

5. Signals of Success

  • Commands and queries are independently scalable and optimised.
  • Complex business logic is isolated from read performance concerns.
  • Real-time views and analytics are powered by projection models.
  • Teams understand and own their side of the command-query boundary.
  • System behaviour is more predictable, observable, and performant.