Why do CQRS read models commonly use denormalized data structures instead of the normalized tables typical of a write-side relational schema, and what does that cost you?

## What denormalization means on the read side **Denormalization** on the read side of CQRS means deliberately storing the same underlying facts more than once, each time pre-shaped for a particular query, rather than storing each fact exactly once in a normalized schema and reconstructing views at request time via joins. Concretely: instead of a normalized set of tables — `orders`, `order_items`, `products`, `customers` — linked by foreign keys, a read model might store a single `OrderSummary` row per order that already contains the customer's name, the list of product names and quantities, and a precomputed total, all copied in at write time. If a customer has 500 orders, the customer's name is now duplicated across 500 rows. That duplication is deliberate: it means answering 'list this customer's orders with product names' is one indexed read of one table, with no join and no runtime aggregation, however large the dataset gets. ## Why teams accept the duplication The reason to do this is **query efficiency and predictable latency at scale**. A normalized schema is optimized for write-side integrity — updating a customer's name in one place updates it everywhere it's referenced — but that same design means every read that needs a 'flattened' view must pay a join cost at request time. - Joins across large tables get slower as data grows. - Complex read patterns (aggregations, cross-entity lookups, full-text search) often need indexes or storage engines the write-side database wasn't built for. CQRS's answer is: don't try to serve every kind of read from one general-purpose schema; instead, build a purpose-specific projection per real query pattern, computed once when data changes rather than recomputed on every read. This is sometimes phrased as **'one read model per view'** — a search page, a dashboard, and a detail page can each have their own denormalized shape, even though they're all derived from the same underlying write-side facts. ## What it costs The cost side of this trade is threefold. 1. **First, storage:** every denormalized copy is additional bytes, and a system with many read models for the same underlying entity can end up storing the 'same' data five or six times over in different shapes. 2. **Second, write amplification:** a single write-side event (e.g., a customer renames themselves) may need to propagate updates into every read model that copied the customer's name — one write becomes N updates, and each of those N updates is a place a bug or an outage can cause drift. 3. **Third, eventual consistency:** because updating the denormalized copies happens asynchronously after the write, there's a window where different read models — or the read model and the write model — briefly disagree, which every consumer of that data has to be designed to tolerate. ## Failure modes Failure modes follow directly from write amplification and duplication. If the process responsible for propagating a change to a given projection fails partway — crashes after updating three of five read models — the system now has silently inconsistent read models until something notices and repairs it, and there's often no built-in signal that this happened, because each read model still 'looks' like valid data. As the number of read models grows, so does the operational burden — every new denormalized view is: - another schema to migrate when a business rule changes - another set of projector code to maintain - another thing to keep in mind when the underlying write-side data model changes shape A common anti-pattern is **'read model sprawl,'** where the team keeps adding projections faster than they can keep them tested and consistent, until nobody fully trusts any of them and staff resort to querying the write database directly 'just to be sure,' defeating the pattern's purpose. ## Where the trade-off shows up at scale A well-known real-world example of this trade-off is a social-media timeline built with **fan-out-on-write**: rather than computing 'show me my feed' by querying all the accounts a user follows at read time (expensive as follow-counts grow), the system denormalizes by writing a copy of each new post into every follower's precomputed timeline read model at post time. This makes reading a timeline a cheap single lookup, at the cost of a write that can fan out into millions of copies for a popular account, and a real engineering problem around handling celebrities' posts differently (hybrid push/pull) because pure fan-out-on-write doesn't scale to that write amplification. The same tension — cheap, denormalized reads bought with more expensive, more failure-prone writes — shows up in any CQRS system that builds dedicated read projections, just usually at a smaller scale than a global social feed.