Command Query Responsibility Segregation — split reads and writes onto different models or even different databases.

Data Flow

Writes: client -> Command -> Write DB (normalised OLTP)
                                              |
                                              v (event / change feed)
Reads:  client -> Query  -> Read DB (denormalised, optimised for search)

When to use

• Read and write scaling needs diverge sharply.
• Complex denormalised read views (e.g. trading dashboards, feeds).
• Different storage tech per side (write -> Postgres; read -> Elasticsearch).

Pitfalls

• Eventual consistency between read and write stores. UI must tolerate small lag.
• Two codebases to evolve.
• Replay / project jobs can lag -> user sees old data after their write.

Analogy

A library: the librarian files new books immediately (write model) but a separate index/ catalogue (read model) is updated periodically for fast search.

Interview tip: State the consistency lag bound (sub-second? minutes?) so the interviewer knows the trade-off.