Read Models

A read model is the result of a projection. It contains the data that the application needs to answer queries – fast, denormalized, and shaped for the use case at hand.

In a system based on CQRS and Event Sourcing, read models are often built from events – through projections that run asynchronously as new events arrive.

In Our Library

Imagine you're a member looking at your profile.

The UI shows:

• All books you currently have on loan
• When each loan is due
• Whether any books are overdue
• What late fees (if any) you owe

All of this comes from a read model – a database table or view specifically optimized for this kind of query.

It's not the same as the data used by the command handler. It's a separate, read-only model, tailored to the user's needs.

Purpose-Built for Queries

Unlike a traditional database schema designed around write operations, read models are designed around questions.

You can create:

• One read model per screen
• Separate models for different users or roles
• Aggregated or flattened views for performance

Because read models are fed by events, you can shape them however you need – without impacting the domain logic or write model.

Eventually Consistent by Design

Read models are not updated instantly – they are updated as events are processed.

This means there's always a slight delay between the write and the read. But in return, you get a system that is scalable, decoupled, and optimized for the user.

Next up: Eventual Consistency – understand the implications of working with delayed reads.