Read Models hold autonomous data

Architecture patterns like CQRS and Event Sourcing construct Read Models to represent the state of the system in a read-only form. These models are entirely made of derived data, been built from original sources like events or data updates. They can be discarded or built up from scratch whenever necessary.

Ideally, Read Models store ready-to-ship information - data serialization in real-time per query invariably leads to performance issues. Such prepared data (especially if the read models are in a schemaless database, can be cached efficiently in a dedicated cache like Redis.

Also, data spread across multiple query models will need joins between tables or documents, leading to reduced scalability and performance. Joins introduce the need for transactions, thus reducing the pattern's effectiveness and limiting the database technologies to choose from.

Besides, storing data in multiple tables or documents in a database that does not support transactions leads to dirty reads. Partial, uncommitted changes will become visible to the user leading to confusion.

For these reasons, data in Read models is best kept self-contained: the model should enclose all data necessary to serve a request.