In CQRS (Command Query Responsibility Segregation), the model used to handle writes is separated from the model used to serve reads. What's the main reason a team adopts this split, and what's the most immediate cost it pays for doing so?
answer
- read/write asymmetry
- two models, one sync pipeline
- eventual consistency window
- projection lag = stale reads
- don't default to CQRS
basics
~20 sReads and writes often need different shapes: writes need consistency and validation, reads need speed and flexible views. Splitting them lets each side be optimized separately — but now you maintain two models instead of one, and they have to be kept in sync.
solid answer
~40 sCQRS earns its keep when read and write workloads pull in different directions — very different query patterns, very different scaling ratios (e.g. 1000x more reads than writes), or a write model shaped for correctness (normalized, transactional) that's a bad fit for reporting-style reads. Splitting lets you scale, model, and even store the two sides independently. The immediate cost is duplication and synchronization: you now build and operate two models, plus a mechanism — usually async projection via events — to keep the read model current, which introduces eventual consistency and an entire new failure surface that a single shared model never had.
go deeper
Should recognize CQRS as splitting read and write models and name asymmetric load/shape as the trigger, and mention 'two things to keep in sync' as the basic cost, even without deep detail on consistency mechanics.
Should explain the sync mechanism (usually events/projections) and articulate the eventual-consistency window as the specific cost, not just 'it's more complex.'
Should be able to weigh a concrete scenario — name when the asymmetry is severe enough to justify it vs. when read replicas or caching would suffice first.
Should frame this as a build-vs-buy-style decision with org-level costs (team ownership of a second model, on-call surface) not just technical cost, and know when to introduce CQRS incrementally on one hot aggregate rather than system-wide.
## What the split actually is CQRS (Command Query Responsibility Segregation) is a **structural split**: instead of one model (one set of classes, one schema, sometimes one database) handling both writes ('commands' — place order, cancel order) and reads ('queries' — show me this customer's order history, show me today's revenue by region), you build two. - **The write side** stays narrow and normalized, focused purely on enforcing business rules and consistency for a single aggregate at a time. - **The read side** is built as one or more denormalized, query-shaped 'projections' — pre-joined, pre-aggregated tables (or even different technology, like a search index for search or a wide columnar store for analytics) — that exist purely to answer specific questions fast. - **A background process** (usually consuming domain events published by the write side) keeps the read models updated as writes happen. ## Why the trade-off gets made The reason this trade-off gets made is **asymmetry**. Most systems don't read and write at the same rate or in the same shape. A social feed might have a 10,000:1 read-to-write ratio; an order system might write in a strict normalized shape (orders, line items, inventory reservations) but need to read in a completely different shape (a dashboard needs revenue-by-day-by-region, a support agent needs one order's full timeline, a customer needs 'my orders'). When one shared model tries to serve both needs, it usually loses on both fronts: - the write model gets polluted with read-optimization compromises (denormalized fields, extra indexes that slow writes); - or the read queries become expensive JOINs that compete with transactional write traffic for the same database's resources, causing writes to time out under load — a very concrete, visible failure mode. CQRS breaks that coupling: - the **write side** can stay small, ACID-transactional, and free of read-shaped indexes; - the **read side** can be scaled horizontally with read replicas, cached aggressively, or even hosted in an entirely different datastore optimized for its query pattern, all without touching write-side code. ## What it costs The cost is real and shows up in three places. 1. **First**, you now maintain two models and, usually, two schemas (or two databases) instead of one — more code, more migrations, more things that can drift out of sync during a refactor. 2. **Second**, you take on eventual consistency: because the read model updates asynchronously after the write commits, there's a window — milliseconds to (if the projection pipeline is backed up) minutes — where a user who just placed an order won't see it in their order history yet. Every screen and every product decision touching a CQRS'd entity now has to answer 'is staleness OK here, and if not, what do we do' (read-your-writes tricks, optimistic UI, or falling back to the write model for that one query). 3. **Third**, there's new operational surface: a projection/replay pipeline that can lag, error, or need to be rebuilt from scratch, monitoring for replication lag, and a second datastore to back up, scale, and secure. ## How it breaks Failure modes in production tend to cluster around the sync mechanism. - **A projector that silently stops consuming events** (a poison-pill message, a schema change nobody updated the projector for) leaves the read model frozen while writes keep succeeding — nothing crashes, but customers start reporting 'my order isn't showing up,' and by the time someone notices, the event log may have rotated past what's needed to catch up cleanly, forcing a full rebuild from the write-side source of truth. - **Another common failure** is treating the read model as authoritative for something it isn't — e.g., using a denormalized inventory count for a 'can I still buy this' check, when the real decision needs the transactional write-side state. ## Where it pays off A concrete scenario: an e-commerce platform's order-write path (place order, reserve inventory, charge payment) needs to be a tight, correctness-first transaction touching a handful of rows. Its 'my orders' page, its warehouse fulfillment dashboard, and its finance revenue report each want a completely different shape of the same data, at much higher read volume, and can tolerate a few seconds of staleness. Splitting into a write model (orders service, relational, transactional) and several read projections (a document store for 'my orders', a search index for support lookup, a rollup table for finance) matches the shape of the model to the shape of the actual traffic, at the cost of the sync pipeline described above. The junior-level takeaway is: don't reach for CQRS by default — reach for it when you can point at a concrete asymmetry (traffic ratio, query shape, or scaling need) that a single model is visibly struggling with; otherwise the two-models-plus-sync-pipeline cost outweighs the benefit.
- How would you decide whether the staleness window in a CQRS read model is acceptable for a given screen?Ask what the user or process does immediately after the write — if they expect to see their own change reflected right away (e.g. 'my order confirmation'), you need read-your-writes handling like routing that one read to the write model or optimistic UI. If the read is for a dashboard or another user's view, a few seconds to minutes of staleness is usually fine. The decision should be made per-screen, not as a blanket policy.
- What's a lighter-weight alternative to full CQRS for the read/write scaling problem?Read replicas of the same database with the same schema — you get read scaling without a second model or projection pipeline, at the cost of not being able to reshape the data for different query patterns. Many teams should try this first and only move to true CQRS (separate models) when the shape mismatch, not just the volume, is the actual problem.
Like a restaurant having a kitchen (write side, optimized for correctly executing orders) and a printed menu board (read side, optimized for customers scanning quickly) instead of making customers read the kitchen's prep tickets — but now someone has to keep updating the menu board whenever the kitchen changes a recipe, and there's a lag between changing the recipe and the board catching up.
saying these in an interview costs you the question
- Says CQRS means using two databases with no mention of why
- Doesn't mention eventual consistency as a cost
- Proposes CQRS for every service regardless of read/write ratio
- Can't name a concrete scaling or shape problem that motivates the split
- Thinks the read and write models must always be different technologies