What is CQRS (Command Query Responsibility Segregation)?

CQRS (Command Query Responsibility Segregation) separates read and write operations into different models. Commands (writes) update one database optimized for writes. Queries (reads) read from a different database optimized for reads. Often paired with Event Sourcing. Allows independent scaling of reads/writes, different data models per use case. Adds complexity—eventual consistency, maintaining sync, more code. Only use when reads/writes have very different needs.

When Should You Use This?

Use CQRS when read and write workloads are vastly different (100:1 read/write ratio), when you need different data models for reads vs writes, when paired with Event Sourcing (event store for writes, projections for reads), or in complex domains where write validation differs from read optimization. Don't use for simple CRUD—adds huge complexity. Most apps don't need CQRS.

Common Mistakes to Avoid

• •CQRS for everything—it's for complex domains, not todo apps
• •No clear boundaries—CQRS adds files/complexity, only use where needed
• •Ignoring eventual consistency—reads lag behind writes, UI must handle it
• •Not worth it—CQRS without Event Sourcing often overkill
• •Wrong problem—read replicas solve most read scaling needs without CQRS

Real-World Examples

• •E-commerce—Write: complex order validation. Read: fast product catalog queries
• •Banking—Write: strict transaction rules. Read: optimized account summaries
• •Event Sourcing systems—Writes are events, reads are projections
• •Complex dashboards—Denormalized read models for instant analytics