Live Projections for Read Models with Event Sourcing and CQRS
Many writings about CQRS and Event Sourcing show the most heavyweight implementation of the query side (aka read models) without even mentioning a more lightweight alternative that even comes without the dreaded “problem” of eventual consistency.
9 min readJan 8, 2022
Disclaimer: CQRS and Event Sourcing are orthogonal concepts. While typically an ES architecture needs CQRS for the query side, CQRS can be implemented without ES, even without Events, and even without separate data storage (e.g. DB tables or EventStores)!
How does the heavyweight “materialized view” implementation look like?
- There is a separate service with a separate database for the query side that hosts a read model (or many — I’ll use the singular form further on)
- The events that populate the read model are published from the event-sourced command side (write model) over a message broker like RabbitMQ or an event streaming platform like Kafka and consumed by the read model
- The event handlers of the read model then persist the changes described in the events into a persistent model — a materialized view — that is optimized for queries, i.e. it can serve queries very fast in a format that is optimized for the client, e.g. a JSON structure that is easy to…
