Read Models

Your events are the truth of what happened, but they’re a terrible thing to query — to show an account balance you’d have to replay every deposit and withdrawal. A read model is the answer to that: a shaped, queryable view of your data, built from events and kept up to date for you. It’s the “read side” of CQRS — the events are the write side.

The power is specialization: one event log can feed many read models, each tailored to a single screen or question. You don’t reuse one model across conflicting needs — you build a focused one per view, so each stays small, fast, and independent.

How a read model gets built

You don’t write to a read model directly — an observer keeps it in sync with the events:

• A projection maps events into the model declaratively — the usual choice.
• A reducer folds events into the model imperatively, when you need more control.

What to read next

Topic	What it covers
Consistency models	The key decision: when does the read model have to be correct — immediately, or eventually?
Getting a single instance	Retrieve one read model instance by its key.
Getting a collection	Retrieve all instances of a read model.
Getting snapshots	Retrieve historical snapshots of a read model’s state.
Watching read models	Observe a read model and react to changes in real time.

To expose a read model to a React frontend, pair it with an Arc query — or see the whole loop in Build a full-stack feature.