Read Models store ready-to-ship information

The CQRS pattern is based on the awareness that data structures of Write Models are fundamentally different from the Read Models in applications. Write Models need to accurately represent the external change, while Read Models are denormalized data formats aimed at improving Data Locality.

Read Models are explicitly built to serve data queries, making sense to store their data in a format close to what is shipped over the wire.

JSON is a popular option. JSON has proven to be flexible enough to fit various use cases, and a majority of applications use it as the primary format to exchange data (compared to XML a few years ago). Databases like MongoDB have an advantage here because they use JSON as the primary persistence format. Applications can simply filter for the right records and ship them directly over the wire in response to data requests.

More importantly, since Multiple read models can be derived from the same data point, one can maintain several read models in different formats to serve the same query. Data is optimized for application-specific requirements, type of client, or medium of exchange.

Hybrid data structures, like a combination of JSON metadata (containing identifiers and queryable attributes) and a binary encoded payload (like Apache Avro), can be maintained for performance-friendly data transfer.

Data in the appropriate format can be shipped depending on the context of the query. For example, a JSON response can be sent to a query originating from a web interface, while an Avro-encoded message can be sent in response to the same query from an RPC-based microservice. Applications can request a data format explicitly by providing a Content-Type HTTP Header, like application/json or avro/binary.