Read Model Projection
A denormalised store built and maintained from write-side events specifically to serve one query shape efficiently.
CQRS separates the write model from the read model. The projection is the mechanism — a consumer that listens to events from the write side and maintains a store shaped for reading.
The advantage is that a read model is optimised for exactly one access pattern, and there can be many of them from the same source: a search index, a dashboard aggregate, a per-customer summary, a denormalised list. Each is independently rebuildable, independently scalable, and its schema is free to diverge from the write model entirely.
The costs to be explicit about:
Eventual consistency, and specifically the case that surprises users: a write followed immediately by a read may not show it. The mitigations are reading your own writes from the write side, returning the new state in the write response, or an interface that reflects the pending action.
Rebuild capability is essential, not optional. Projections have bugs and requirements change, so the ability to drop a read model and rebuild it from the event history is what makes the pattern safe — and it must be tested at production data volume, because a rebuild that takes eleven hours is a different operational fact from one that takes ten minutes.
Projection lag needs monitoring and alerting, since a stalled projection presents as stale data rather than as an error.