CQRS and read models

Distributed systems Senior Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Pick the fix

Search and dashboards need very different views of orders than checkout does, and complex joins are slowing checkout. Which approach is CQRS?

Options
Hint 1 of 1

Separate the shapes for reading and writing.

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Keep writes in PostgreSQL and project changes into a search index and summary tables for reads

Correct. Separate read models built from the write side's changes.

CQRS splits the model you write to from the models you read from. Checkout writes stay normalised in PostgreSQL, and search and dashboards read projections fed by those changes.

Why not the others?
  • B Add more indexes to the orders table. Helps reads but loads the write path more.
  • C Put everything in one big denormalized table. That merges the models instead of separating them.
  • D Cache every query result for an hour. Caching isn't a separate model and can serve hour-old data.

30-second answer

Command Query Responsibility Segregation separates the model that handles writes from the models that serve reads. Writes go through one normalized model that enforces the rules; events or change data capture then update read models shaped for each screen or query, possibly in different stores such as a search index. It's worth it when reads and writes have very different shapes or scale. The cost is eventual consistency between the two sides and more moving parts.

Practise saying it · 35 s. No recording, just a timer

Explain CQRS.

Say your answer out loud, then check which of these points you covered:

  • Separate write and read models
  • Read models fed by changes
  • When shapes differ
  • Eventual consistency cost
  • Rebuildable projections

Deep dive

Often paired with event sourcing, but it doesn't require it.

A simple form: the same database with materialized views or summary tables.

Read models must be rebuildable from the source of truth.

The UI has to handle 'saved but not visible yet' (show the user's own change optimistically).

Common mistakes

  • Applying CQRS to plain CRUD screens.
  • No way to rebuild a corrupted read model.
  • Hiding the eventual consistency from product owners.

Senior take & follow-ups

Define the split, say when it pays off, and name the consistency and complexity costs.

Follow-up questions

Think of your answer first, then open the hint.

  1. CQRS vs event sourcing?

    Show hint

    CQRS splits read and write models; event sourcing stores state as an event log. Independent choices.

  2. How stale can read models be?

    Show hint

    Measure the projection lag and alert on it.

Related questions

Suggest a fix if something here is wrong or out of date.