---
title: "CQRS | Skills We Assign For | Azendo"
description: "CQRS in practice — when separating read and write models earns its cost, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/cqrs/"
---

[Skills](https://azendo.co/skills/) Architecture and patterns 

# CQRS.

CQRS separates the model that changes state from the model that reads it, so writes and reads can be shaped, scaled and optimised independently. It is a targeted answer to systems where the two have genuinely different requirements, and an unnecessary tax on systems where they do not.

## Where CQRS fits on a long engagement.

CQRS is worth its complexity when the read and write sides pull in incompatible directions: a write model that must enforce invariants transactionally, and a read model that must answer aggregate questions across millions of rows without touching the same tables. Splitting them lets each be correct on its own terms.

Applied without that pressure it is expensive for nothing. Two models to keep in step, a synchronisation path to operate, and eventual consistency that the interface now has to explain to a user who just saved something and cannot see it. The pattern is a response to a specific problem, and the honest first question is whether the system has that problem yet.

## What an assigned team does with CQRS.

The cost of CQRS is not in building it, it is in living with it. Every subsequent feature has to decide which side it touches, and eventual consistency has to be handled in the interface rather than hidden. That is ongoing design discipline rather than a one-time architectural act.

Holding a pattern consistently over years is what a standing assignment is for; it is the part that erodes fastest when different people implement each feature. How direction and delivery divide in that arrangement is set out in [how an assignment runs](https://azendo.co/how-it-works/).

## What we use CQRS for.

* Reads and writes with incompatible shapes A transactional write model beside a denormalised read model, each optimised for what it actually does.
* Reporting that must not affect transactions Analytical queries served from a separate model, so a heavy report cannot slow the path that takes orders.
* Scaling one side independently Read capacity grown without touching the write path, where the traffic ratio makes that the cheaper axis.

## How CQRS capacity is assigned.

CQRS work is assigned inside backend capacity under [software development outsourcing](https://azendo.co/services/software-development/), with the decision to adopt it treated as a scoping question rather than a default.

## Roles we assign CQRS for

* [Software Architect Software development](https://azendo.co/services/software-development/software-architect/)

## Service lines it sits in

* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in architecture and patterns

* [Domain-driven design — skill we assign for](https://azendo.co/skills/domain-driven-design/)
* [event-driven architecture — skill we assign for](https://azendo.co/skills/event-driven-architecture/)
* [microservices and modular monoliths — skill we assign for](https://azendo.co/skills/microservices-and-modular-monoliths/)
* [AWS and Azure reference architectures — skill we assign for](https://azendo.co/skills/aws-and-azure-reference-architectures/)
* [Double-entry ledgers — skill we assign for](https://azendo.co/skills/double-entry-ledgers/)
* [Multi-tenant architecture — skill we assign for](https://azendo.co/skills/multi-tenant-architecture/)

## Tell us what your roadmap needs CQRS for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)