In traditional CRUD systems, both reads and writes are performed using the same data model and the data flows the same way. The titular segregation basically means to treat queries (reads) and commands (writes) in two separate ways.
Many applications have a strongly biased ratio of reads to writes – there's usually a lot more reading from the database than updating it in a typical app. This means making the reads as fast as possible can yield better performance: reads and writes can now be optimized and scaled separately. Other than that, introducing CQRS can help if many writes are competing with each other, or if a track of all the writes needs to be maintained, or if a set of your API users should have read-only access.
Having separate models for reads and writes can allow having different teams to work on both sides. The developers working on the read side of things don't need to have a deep understanding of the domain, which...
