Command Query Responsibility Segregation suffers from its own branding, because the name sounds like a heavyweight architecture, and most descriptions jump straight to the version with event streams, separate databases and eventual consistency, which is the pattern's most extreme dialect. The core idea is humbler and more useful, the shape of a good write is not the shape of a good read, and forcing one model to serve both produces the model that serves neither well. This article builds the idea from the modest version upward, the single database with separate models, the read model as a first class artifact, the eventual consistency dialect and its user facing consequences, and the honest boundary where the split is complexity without a payer.
The asymmetry that the single model papers over
The write wants invariants. It arrives as a command, create this order, transfer this balance, and the model's job is to refuse what breaks the rules, in a transaction, with the aggregate's full invariant surface loaded and armed. The shape is normalized, richly connected, every entity in its place, because the rules span the entities and the rules are the write's product. The read wants none of that. It wants a page shaped answer, the order with its customer name, its line item titles and its computed totals, denormalized exactly as the screen displays it, and loading the invariant armed object graph to produce that shape is the classic read path cost, the join cascade, the N plus one, the hydrate to render two fields.
The single model serves the write, because the write is where correctness lives, and the read pays for it with an object relational impedance on a good day and a query service on a bad one. The segregation answer is to admit the asymmetry, keep the write model as the invariant guardian, and give reads their own model, shaped for the query, maintained by the system rather than assembled per request. The modest version keeps both models in one database, the read model as a view, a materialized projection, a denormalized table the write path updates in the same transaction, and the split is a modeling decision that costs one table and one update statement.
-- write model, normalized, invariants live here
UPDATE orders SET status = 'paid' WHERE id = $1;
-- read model, shaped for the orders page, same transaction
UPDATE order_page_cards
SET status_label = 'Paid', paid_at = now()
WHERE order_id = $1;The orders page reads the card table directly, one query, no joins, no hydration, and the invariant model never appears on the read path at all. The cost is the write model knowing the read shapes exist, the update statement above is a dependency the rename will touch, and the cost is real, modest, and the reason the extreme dialect exists.
The read model as a first class artifact
Promoting the read model from an accident of queries to a designed artifact is where the pattern becomes an architecture. The read model has a schema chosen for its queries, the dashboard table with the counters precomputed, the listing table with the search columns indexed as queried, and it has a lifecycle, built from the write model by a projection, rebuilt from scratch when the shape changes. The projection, the code that turns write model changes into read model rows, is the pattern's working part, and the earlier event sourcing article built it from events, which composes but is not required, the projection from the write model's own tables inside one transaction is the same architecture at one database.
The read model's value concentrates where the read shape diverges hardest from the write shape, the reporting surface, the search indexes, the recommendation and personalization features, the pages whose queries would need six joins across four aggregates. Each of these is a projection, each is rebuildable, and the rebuild property is what makes the divergence safe, because a defect in the projection is fixed by rebuilding it, and the write model, the invariants, was never touched. The teams that adopt the modest version usually report the same discovery, half their slowest queries were read paths assembling write shapes, and the card table cut the database's evening load in half.
The eventual consistency dialect and its user facing honesty
The extreme dialect separates the databases and makes the projection asynchronous, the write commits in one store, the projection applies from a stream or a log, and the read model trails by the propagation time. The dialect is the standard companion of event sourcing, the log is the transport, and it is also the architecture of the read replica, the search cluster, the cached pages, any system where reads serve from a copy that updates after the fact. The engineering cost is the machinery, the stream, the subscriber, the position tracking, the monitoring of the lag, all of it familiar from the replication and Kafka discussions in this series.
The honest cost is the user's. The read model trails, and the interface must decide what the user sees during the trail, the classic write your own reads problem, the profile update that saves and renders the old name for three hundred milliseconds. The solutions are a small toolbox, the read your own writes routing for the user's own writes, the UI that renders the optimistic response and reconciles, the staleness indicators for the data that tolerates it, and the design conversations that classify each read, does this query need the last write or does it need a good enough yesterday. The write your own reads routing has a mechanical shape, the write stamps a token with the write's position, and the read for that user waits for the projection to pass it:
def save_profile(user_id, patch):
position = write_model.update(user_id, patch)
session["read_barrier"] = position # the user's next reads wait for this
def read_dashboard(user_id, session):
barrier = session.get("read_barrier")
projection.wait_for_position(barrier, timeout=50ms)
return read_model.dashboard(user_id)The wait is bounded, a few tens of milliseconds on a healthy projection, and the user's own view never regresses in front of their own eyes, which is the whole of the problem and the whole of the solution. The dialect is the right architecture when the read scale genuinely needs the separation, the read side at ten times the write side, the search and analytics surfaces that want their own storage, and it is the wrong architecture when a materialized view in one database delivers the same page, because the eventual consistency tax is paid in every user facing defect the trail produces.
The report that locks the truth, one seam walked through
The seam that usually triggers the pattern arrives as a performance incident. The finance team's monthly summary runs over the normalized model, six aggregates joined and folded per page of output, and the query plan that took nine seconds in staging takes four minutes in production, holds the locks the checkout path needs, and the write side queues behind a report. The modest dialect answers inside one database:
-- built nightly by one projection query
INSERT INTO finance_monthly
SELECT date_trunc('month', o.created_at) AS month,
c.segment,
sum(oi.price * oi.quantity) AS revenue,
count(*) AS orders
FROM orders o
JOIN order_items oi ON oi.order_id = o.id
JOIN customers c ON c.id = o.customer_id
GROUP BY 1, 2;The finance page reads the summary table, the transactional model never sees the finance query again, and the locks that queued the checkout disappear because the query that held them stopped running. The projection is scheduled, the table is rebuildable by definition, and when the finance team invents a new column, the change is one line in the projection and one rebuild, not a new join cascade on the production path. The walk-through is the pattern's whole adoption case in one seam, the read shape diverged, its cost was measured in the write path's incident, and the read model moved it out.
The read replica as the dialect everyone already runs
Most teams run a dialect of this pattern without calling it that, the read replica, the streaming copy of the database the reports and dashboards query. The replica is CQRS with the identity projection, the read model has the same shape as the write model and the segregation is physical, and the separation is bought for the same reason, the reads that would hurt the writes are pointed somewhere they cannot. The promotion path from the replica to the shaped read model is incremental, the dashboard that hammers the replica with the same six join query becomes the dashboard that reads the summary table, the table built from the replica itself, and the lag the replica already carries is the lag vocabulary the eventual dialect reuses.
The teams that recognize the replica as dialect zero adopt the rest of the pattern without ceremony, because the operational machinery, the lag monitoring, the rebuild, the staleness classification, is the machinery they already run for replication, and the question per new surface is merely which dialect, the view, the table, the separate store, each priced by the same seam evidence.
The dogma trap on simple systems
The pattern's failure mode is adoption as identity, and the failure is recognizable in the code review. The simple product, a few entities, the writes modest, the reads one join, ships with a command bus, two databases, a projection framework and an eventually consistent admin interface, and the first defect report is the stale read the team engineered on purpose. The dogma trap is identical to the ones this series has flagged in the architecture and framework discussions, the ceremony purchased before the requirement existed, and the diagnostic question is the same one this article opened with, is there a read whose shape actually diverges from the write, with a measured cost.
The simple system that wants the modest version can have it with one view and no architecture, and the simple system that was sold the extreme version should keep its transactional consistency and its single database, because the user visible behavior of a small well indexed application is indistinguishable from its segregated twin, except the twin has two failure domains and a lag dashboard. The pattern earns its adoption at the seams where the product actually strains, the reporting that locks the transactional tables, the search that wants an index engine, the scale asymmetry that needs the read tier to grow alone, and each of those seams is visible in the metrics before anyone proposes the architecture.
The working rules for the split
The decision and the implementation discipline fit in one list, and the list is short:
- Keep the write model small, invariant rich, and transactional, it is the system's source of truth;
- Introduce read models per divergent shape, the card table, the report, the search index, never per fashion;
- Start every read model in the same database, the separate store is a scale decision the metrics must justify;
- Make every read model rebuildable, the projection is code and the rebuild is its test;
- Classify reads for staleness tolerance, and design the write your own reads path for the intolerant ones;
- Rehearse the projection failure, the read model that dies must rebuild while the writes continue.
The separation is a tool with two dialects and one idea, the read shape is a design decision the write model should not tax, and the team that starts with the modest dialect and promotes it per measured seam gets the performance of the divergence without ever paying for a dialect it did not need. The writes stay clean because they only carry truth, the reads stay fast because they only carry the page, and the system between them is the small, explicit, monitored machinery that keeps the two honest.
The modest dialect, one database and shaped tables, is the version most products should run, and the extreme one is a promotion the seam evidence makes on its own schedule, which is the entire architecture expressed as a deployment decision.