CQRS, or **Command Query Responsibility Segregation**, is a software architectural pattern that separates the operations that modify data (**commands**) from those that read data (**queries**). This distinction allows each side of the system to evolve independently and scale according to its specific needs.
# Origin The pattern was **formalized and popularized by Greg Young** in the late 2000s, building on earlier ideas from Bertrand Meyer’s *Command–Query Separation* principle (1990s). CQRS emerged alongside Event Sourcing and Domain-Driven Design, forming a triad of mutually reinforcing patterns.
# Key Ideas - **Command vs Query**: A *command* changes the system’s state and returns no data. A *query* retrieves data but does not alter state. - **Separation of Models**: Systems often maintain two distinct models: - A **write model** that enforces domain rules and emits events. - A **read model** that provides fast, denormalized views optimized for querying. - **Scalability and Flexibility**: The separation enables each side to be scaled, cached, or optimized differently. Read models can even use entirely different storage technologies. - **Event Integration**: CQRS often pairs with Event Sourcing—commands produce events that update both the write model and asynchronously rebuild the read model.
# Benefits - Clearer domain boundaries and intent - Easier horizontal scaling and performance tuning - Strong fit with asynchronous and distributed architectures - Natural foundation for event-driven systems
# Notable Contributors - Greg Young — Principal author and advocate of CQRS. - Udi Dahan — Early collaborator and educator on distributed CQRS systems. - Martin Fowler — Helped document and explain the pattern to a broader audience. - Eric Evans — Provided the conceptual foundation via Domain-Driven Design.
# Sources
- martinfowler.com 
- gregyoung.me
- udidahan.com
- dddcommunity.org
# See