Architecture
CQRS
Command Query Responsibility Segregation splits the write model from one or more read models optimised for querying, often updated asynchronously. It shines when read and write shapes or loads differ sharply, and it pairs naturally with event sourcing. It adds real complexity and eventual consistency between the sides, so apply it to hot subdomains, not everywhere.
Purpose
CQRS — Command Query Responsibility Segregation — separates the write model (commands that change state, guarded by business rules) from one or more read models shaped purely for fast querying. It exists because the shape that makes writes correct is rarely the shape that makes reads fast.
When to Use It
It earns its keep when reads and writes differ sharply in load or shape: a heavily-queried dashboard over a transactional core, search projections, feeds. It pairs naturally with event sourcing, where the write side emits events and read models are projections of them.
Trade-offs
Two models mean two schemas, synchronisation code and — when the read side updates asynchronously — eventual consistency that the UI must tolerate ('your change may take a moment to appear'). Applied everywhere it doubles the codebase for no gain; applied to the one hot subdomain, it is surgical.
Implementation
Start light: same database, separate read queries or views from command handlers. Scale up only as needed — a denormalised read table updated by events, then perhaps a separate store. Keep commands intention-revealing (CancelOrder, not UpdateOrderStatus) and let projections be rebuildable from the event history.