Command Query Responsibility Segregation is an overloaded “term”. It is often confused or muddled with Event Sourcing. The two can go together nicely, but they do not have to.
What Is It
CQRS is really the principle and practice of separating data reads and data updates. This does not dictate at which layer that separation exists. It could be separate methods in the code. It could be separate databases.
The idea behind the principle is a bit more involved than that simple explanation. The term ‘command’ in the name hints at that. Rather than simply constructing the data operations as the traditional CRUD (Create Read Update Delete) operations, the data mutations are represented as commands. These commands capture the user’s intent better. Rather than issuing an “update person” operation, a command looks more like “change person’s first name to…”
Commands tend to have a narrower context than the create and update mutations. They more naturally follow the business use cases. The command pattern is common in a microservices architecture. This is because they tend to have a narrow context, are idempotent, and are not very volatile. What I mean by ‘volatile’ is that it can be hard to determine which generic “update” mutation should be accepted when there is a conflict. But multiple simultaneous commands are much less likely to conflict with each other.
Resources
Pluralsight has some great courses on CQRS, and also on Event Sourcing. Martin Fowler also has a good post on CQRS.