CQRS as a Data Architecture

Definition

At the data-architecture level, CQRS is the decision that the store you write to and the stores you read from are different systems, with the read stores derived asynchronously and treated as disposable.

Why the "disposable" part matters most

The single most valuable property of a derived read model is that it can be rebuilt from scratch. That changes the risk profile of every bug in it: a wrong projection is an inconvenience to be re-derived, not a data-loss incident. Systems where the read model has accumulated state that exists nowhere else have lost this property, usually without noticing, and it is worth testing that a rebuild actually works before you need it.

Industry example

LinkedIn's serving architecture is a good illustration of the shape at scale. The authoritative record of a member's profile or a company's data lives in a transactional store. What actually serves traffic is a set of derived systems: a search index, a graph store for connection traversal, various denormalised views for feed and recommendation, each built by consuming a change stream from the authoritative source.

Two consequences are worth internalising:

The change stream becomes the integration backbone. Once every derived store is built by consuming changes, adding a new derived store requires no change to the writer at all. This is the same argument that motivated a central log in the first place, and it is why CQRS and event streaming tend to arrive together even though neither requires the other.

Every derived store has its own lag, and they differ. Search may be seconds behind while the graph is milliseconds behind. A user action that touches both can produce a visibly inconsistent experience, and the product has to decide which inconsistencies are acceptable rather than pretending none exist.

Implementation patterns

• Keep the write model authoritative. Any decision with a real consequence re-checks it.
• Version the projection logic so a rebuild is reproducible and a change can be rolled out by building a new projection alongside the old.
• Expose staleness — a timestamp or version — so consumers can reason about it.
• Read-your-own-writes for the acting user, served from the write model or a session cache. This removes most perceived weirdness at very low cost.
• Monitor projection lag as an SLI, because a stalled projection produces no errors.

Failure scenarios

• The read model becomes authoritative by accident — a workflow writes to it, or a report is reconciled against it — and it can no longer be rebuilt.
• Rebuild never tested, so the one time it is needed it takes four days.
• A projection bug corrupts data silently, and because nobody versioned the logic, it is unclear which records are affected.
• CQRS applied to simple CRUD, where one model served both perfectly.

Interview question

"Your search index has been serving results built by a projection with a bug for three weeks. Walk me through the recovery."