In a CQRS (Command Query Responsibility Segregation) system, commands update a write model and queries read from a separate read model that is synchronized afterward. Why does a user sometimes not see their own change immediately after saving it, and what do engineers call the time window during which this can happen?
answer
- write model vs read model
- async projector/CDC
- outbox pattern
- convergence, not immediacy
- lag = commit time to read-model-updated time
basics
~20 sThe read copy of the data updates a little after the write copy, through a background sync step. Until that catches up, queries can show old data. That gap in time is called the lag window (or replication lag).
solid answer
~40 sCQRS splits the model that handles writes from the model optimized for reads; they're kept in sync asynchronously (via events, a message bus, or change-data-capture) rather than in the same transaction. That asynchronous propagation takes non-zero time - the 'lag window' or 'replication lag' - during which the read model can return data that doesn't yet reflect the latest write. This is eventual consistency: guaranteed to converge, not guaranteed to be immediate. Window size depends on event-bus latency, projector throughput, and batching, ranging from single-digit milliseconds (in-process handlers) to seconds or minutes (queued, cross-service projections). Teams accept this trade-off because it lets the read side scale and be modeled independently, at the cost of needing explicit handling for read-after-write expectations.
go deeper
Should recognize that write and read sides are separate stores updated asynchronously, and be able to name 'eventual consistency' or 'lag window' as the reason for stale reads; not expected to design mitigations yet.
Should describe the propagation mechanism (events, CDC/outbox) and estimate what drives lag size, and know this needs explicit handling in UX (spinners, optimistic UI, read-your-writes).
Should design and instrument the propagation pipeline, choose synchronous vs asynchronous per use case, and put SLOs and alerts on lag.
Should set org-wide guidance on when eventual consistency is acceptable versus when a use case demands synchronous reads, and own the trade-off across many read models and services.
## How a write reaches the read model **CQRS** separates command handling, which mutates the authoritative 'write model' (typically a normalized schema enforcing business invariants), from query handling, which reads from a separate 'read model' — often denormalized or materialized specifically for a UI screen or report, such as a document store, a search index, or a set of precomputed aggregates. Crucially, the two are not updated inside the same database transaction. When a command commits, the write side typically emits a domain event, or a row change is captured via **change-data-capture (CDC)** or a **transactional outbox**, which travels through some channel — an in-process event bus, a Kafka topic, an outbox-polling job — to one or more **projectors** that translate the event into an update against the read store. Each hop adds latency: - event publish - transport - consumer pickup - projection write - cache invalidation, if fronted by a cache The cumulative delay between the write committing and the read model reflecting it is the **lag window**. ## Why the two sides were split apart This split exists because write and read workloads have fundamentally different shapes: | Side | What it needs | |---|---| | Writes | need strict invariant enforcement, and often benefit from normalization and locking | | Reads | need to be fast, denormalized, and horizontally scalable, frequently serving far higher volume than writes ever do | Coupling both concerns into one schema and one transaction, as classic CRUD does, forces compromises on both sides: - either the write schema gets denormalized for read convenience (risking inconsistent invariants), - or the read queries stay slow and awkwardly shaped around normalized tables. CQRS lets each side scale and evolve independently — read models can be reshaped or entirely rebuilt without touching write logic, and multiple specialized read models (a search index, a cache, an analytics warehouse) can all be derived from the same stream of write-side events. ## The trade-off The trade-off is explicit: - **You gain** independent scalability and read models tailored exactly to query needs. - **You pay** with eventual consistency. Any code path that assumes 'if I just wrote X, reading X back will show the new value' breaks unless it's specifically designed around the lag window (see read-your-writes techniques). - **You also pay** with more moving infrastructure — an event bus or CDC pipeline, one or more projector processes, and the operational burden of monitoring and occasionally rebuilding/replaying read models from scratch when their shape changes or they get corrupted. ## Failure modes Several concrete failure modes show up in production. 1. **A projector can simply fall behind under load**, so the backlog and observed lag both grow monotonically until someone scales it out. 2. **A single malformed or unexpected event** — a 'poison message' — can stall a consumer entirely, freezing the read model at a fixed point in time until an engineer intervenes, which is a much worse failure than ordinary lag because it doesn't recover on its own. 3. **Events delivered out of order** (common across partitions in a distributed log) can, if the projector isn't order-aware, apply updates in the wrong sequence and leave the read model in an incorrect end state rather than just a temporarily stale one. 4. **Duplicate delivery**, which most at-least-once messaging systems guarantee will eventually happen, can double-apply an effect (e.g., incrementing a counter twice) unless the projector logic is idempotent. 5. **The write-side outbox or CDC pipeline itself crashes mid-batch**, and a read model can end up with a partially-applied event, inconsistent even within its own fields. ## Where it shows up A concrete, widely recognizable example: an e-commerce catalog where product edits go through a write-side service backed by a relational database, and a Debezium-style CDC pipeline streams row changes through Kafka into an Elasticsearch index that powers site search. A seller updates a product's price, and the write commits instantly in the source database — but the change only appears in search results once: 1. the CDC connector picks it up, 2. Kafka delivers it, 3. the Elasticsearch indexer applies it — typically a few hundred milliseconds to a few seconds later under normal load. Engineers on such systems commonly expose an 'index freshness' or 'connector lag' dashboard specifically to keep this window bounded and alertable, because customers and internal support staff will otherwise report it as a bug rather than recognize it as the expected, monitored trade-off CQRS makes by design.
- What determines whether the lag window is milliseconds or minutes?Mainly the transport used - an in-process synchronous event handler is near-instant, while an external queue with a polling projector adds real delay. Projector throughput, batching interval, and any backpressure under load also directly control the size of the window.
- Is eventual consistency the same as the read model being simply unreliable?No - eventual consistency is a guarantee that the read model will converge to the correct value given no further writes, whereas 'unreliable' implies no guarantee at all. The distinction matters: you can design around a bounded, monitored lag window, but you can't design around an undefined consistency model.
- How would you actually observe the lag window in a running system?Emit a timestamp when the write-side event is produced and another when the projector applies it to the read model, then track the difference as a latency metric (ideally a p50/p99 histogram). A synthetic canary write, probed repeatedly against the read API until it appears, gives an outside-in measurement of what users actually experience.
Think of a company's live sales dashboard fed from the checkout database via a streaming pipeline: the moment a sale closes it's already true in the ledger, but the dashboard tile only ticks up once the pipeline processes that event a few seconds later - same real-world fact, two clocks.
saying these in an interview costs you the question
- says CQRS always requires two separate physical databases
- claims read-model updates happen instantly by default
- conflates eventual consistency with no consistency guarantee at all
- can't name any mechanism (events/CDC/outbox) connecting the write and read sides
- thinks the lag window is a fixed constant regardless of load or deployment