CQRS Overview

The Workload Asymmetry

 most systems: reads DWARF writes (100:1 to 1000:1)
 and their OPTIMAL SHAPES differ:

 WRITES want:
   normalized data, constraints, small rows, correctness first

 READS want:
   denormalized views, pre-joined, shaped EXACTLY per query

 one table shape serving both = compromise everywhere.

The Split

        COMMANDS                    QUERIES
   (change state)              (answer questions)
        │                           │
   ┌────▼─────┐    events      ┌───▼────────┐
   │ write    │ ─────────────► │ read models │
   │ model    │  projection/   │ - search idx│
   │ (normal- │  CDC/sync      │ - dashboards│
   │ ized DB) │                │ - api views │
   └──────────┘                └─────────────┘

 commands NEVER query read models for validation decisions;
 queries NEVER touch the write store.
 each side scales, schemas, optimizes independently.

What Each Side Looks Like

Aspect	Command side	Query side
Data shape	normalized, constrained	denormalized per view
Consistency	strong, transactional	eventually synced
Scaling	vertical/sharded carefully	replicas, caches, CDNs
Schema changes	careful migrations	rebuild projections freely
Tech examples	postgres, mysql	elasticsearch, redis, read replicas

 the sync between them:
 same-database replicas (simplest CQRS!) →
 CDC pipelines → event-driven projection updates.
 a spectrum of lag vs complexity — pick per view.

The Full Spectrum (don’t max out by default)

 LEVEL 0: single database, both roles         ← most apps!
 LEVEL 1: primary + read replicas             ← very common ✓
 LEVEL 2: specialized read stores per need
          (search → elastic; counters → redis)
 LEVEL 3: full CQRS+ES with event-sourced write side

 jump levels ONLY when measurements demand it:
 level 2+ costs ops surface, eventual-consistency UX,
 double schema maintenance. the ladder applies here too.

When CQRS Earns Its Complexity

 □ genuinely divergent query shapes (search + transactions +
   analytics on same domain)
 □ independent scaling curves (reads exploding past writes)
 □ event sourcing present anyway (projections are natural)
 □ team boundaries align with the split

 skip when:
 ✗ standard CRUD with moderate traffic
 ✗ team too small to operate sync pipelines
 ✗ "we might scale someday" (speculative — YAGNI's home turf)

Interview Framing

“Product catalog: heavy search traffic, strict inventory writes” scored shape: recognize workload split, propose write-model (postgres, transactional inventory) + read-models (elastic for search; cache for detail pages), sync via CDC, staleness handling for UI (“added-to-cart revalidates against write store”). Naming Level-1-as-starting-point shows you climb ladders only as needed — the calibrated answer interviewers wait for.