CQRS Read Model

Concepts Covered

• CQRS
• Write models
• Read models
• Derived projections
• Denormalization
• Eventual consistency
• Query optimization
• Rebuildability

1. Intent

CQRS means Command Query Responsibility Segregation.

The core idea is to separate the model used for writes from the model used for reads.

The write model preserves correctness, validation, and source-of-truth state. The read model is shaped for fast product queries.

2. The Problem Without This Pattern

One database model rarely serves every need perfectly.

A normalized write model may preserve correctness but make reads expensive. A denormalized read model may be fast but harder to update correctly.

Trying to force one model to do everything can produce slow queries, fragile joins, and write paths polluted by read-specific concerns.

Example:

source truth: post_likes(user_id, post_id)
feed read: needs like_count for 30 posts

Counting likes directly from the source table on every feed request is correct but expensive. Storing only the count is fast but loses the relationship truth.

CQRS keeps both ideas separate.

3. How The Pattern Works

General shape:

commands -> write model -> events -> read model
queries  -> read model

The write model owns truth and validation. The read model is shaped for specific queries.

In a like system:

write model: post_likes
read model: post_like_counts

In a chat system:

write model: messages, receipts, membership
read model: user_conversation_inbox

The read model may be updated synchronously for simple systems or asynchronously through events for scalable systems.

4. When To Use It

Use CQRS-style read models when:

• read and write access patterns are very different
• reads need denormalized or precomputed data
• derived views can be eventually consistent
• the source of truth remains clear
• query latency matters
• a single normalized schema creates too many joins or scans

Good examples:

• like count projections
• conversation inboxes
• unread counters
• analytics dashboard tables
• search index documents

5. When Not To Use It

Avoid CQRS when:

• simple CRUD is enough
• strong read-after-write consistency is required everywhere
• the team cannot operate projection pipelines
• duplicated data would create more risk than benefit
• there is no clear owner for read-model freshness

CQRS is not a badge of sophistication. If one model works and traffic is modest, keep the system simpler.

6. Data And Operational Model

Read models need:

• a source of truth
• an update mechanism
• freshness monitoring
• rebuild strategy
• schema ownership
• drift detection
• backfill tooling

Operators should monitor:

• projection lag
• query latency
• rebuild duration
• drift from source truth
• failed projection updates
• schema migration progress

The read model should be rebuildable. If the only copy of useful data lives in a derived read model, it has quietly become the source of truth whether the team admits it or not.

7. Failure Modes

• Read model gets stale.
• Projection logic misses events.
• Users see inconsistent data without explanation.
• Rebuild path is missing.
• Teams forget which model is authoritative.
• Read model schema changes without replay support.
• Backfill overloads the source database.

8. Tradeoffs

Benefit	Cost
Fast read queries	Duplicate data
Clear write ownership	Projection lag
Models fit access patterns	More moving parts
Supports scale	Needs repair and rebuild logic
Reduces read-path joins	Requires freshness contracts

CQRS read models are powerful when the read path needs a different shape than the write path. The price is operating projection pipelines honestly.

9. Related Systems And Concepts

• Instagram Likes System
• WhatsApp-Style Messaging System
• Derived Projections
• Eventual Consistency
• Projection Drift
• Reconciliation Job