Direct DB Queries → CQRS Read Models
HighSeparating the write model (commands to a normalized database) from the read model (denormalized projections optimized per query pattern), enabling independent read/write scaling at the cost of read model staleness and projection maintenance complexity.
Topology Changes
From
Unified Read/Write Database
To
CQRS with Separate Read Projections
Topology Mutations
Dedicated read store optimized for query pattern: search engine for full-text, cache for hot reads, denormalized schema for complex aggregations
Operational Impact
New operational surface: projection lag monitoring, rebuild procedures, index mapping updates
Write commits trigger event emission that drives projection updates: via domain events, CDC, or direct projection writes
Operational Impact
Projection staleness window = pipeline latency; pipeline failure causes read model to fall behind indefinitely
Write path (commands) and read path (queries) are separated in application code and infrastructure
Operational Impact
Code complexity increases: write and read models must be maintained independently
Reads from projection store may be milliseconds to seconds behind the write store
Operational Impact
Read-after-write consistency violations are possible: user who just wrote may see stale data on next read
Migration Stages
Catalog all current read query patterns. Group by shape. Identify which patterns would benefit from a separate projection. Identify which patterns require strong read-after-write consistency and must stay on the write store.
Deploy read store infrastructure (Elasticsearch, Redis, read replica schema). Set up projection lag monitoring. Define projection rebuild procedures.
Build initial projection by reading from the write store and populating the read store. Validate data consistency. Measure projection population throughput.
Application reads from both write store and projection in parallel. Compare results. Identify consistency gaps and projection correctness issues before switching read traffic.
Gradually migrate read traffic from write store to projection store. Route non-consistency-sensitive reads to projection first. Retain write store reads for immediate-post-write scenarios.
Remove direct read queries from the write path. Write store now handles commands only. Implement projection update pipeline (CDC or domain events).
Migration Risks
Projection lag creates a read-after-write window where users see stale data after their own writes
Mitigation
Route immediate post-write reads to the write store (session-scoped write token); accept eventual consistency only for non-user-initiated reads
Projection rebuild after schema change can take hours or days on large datasets
Mitigation
Design blue/green projection deployment: build new projection in parallel before switching traffic; test rebuild time in staging
Projection pipeline failure causes read model to silently fall behind: no error surfaced to users
Mitigation
Monitor projection lag as a critical alert; implement circuit breaker to fall back to write store reads when lag exceeds threshold
Write store schema changes may require projection rebuild or migration
Mitigation
Version projection schemas independently; use CDC with schema registry to decouple write and read schema evolution
Coupling Changes
Read and write paths scale independently: read store can be scaled without touching write infrastructure
Consequence
Read store technology can be chosen for query pattern (search engine, columnar, cache) rather than write constraints
Application must reason about projection lag and choose read source per operation
Consequence
Every read operation now has an implicit choice: strong consistency (write store) vs low latency (projection)
Projection pipeline health determines read model accuracy: pipeline failure affects all reads
Consequence
Projection pipeline becomes a critical dependency requiring the same SLA as the write store
Consistency Model Changes
- ·Write store remains strongly consistent: all commands produce ACID-consistent state
- ·Projection reads are eventually consistent: staleness window determined by pipeline latency
- ·Read-after-write consistency requires explicit routing to the write store for the requesting session
- ·Projection accuracy must be validated: data drift from pipeline bugs may be invisible until user-reported
Rollback Risks
- ·Removing direct read queries from write path requires re-adding ORM queries or SQL if rolling back
- ·Projection pipeline configuration and topic offsets cannot be rolled back without replaying from earliest offset
- ·Product UX changes to handle eventual consistency are difficult to roll back after customer exposure