WIP

Summary

CQRS describes splitting responsibility for providing write behaviour and read behaviour into two separate systems. This allows for more intelligent scalability as resource for either read of write systems can be increased independently leading to optimised performance and cost management.

What does it look like?

This depends on your overall architecture. CQRS lends itself to event-driven solutions as events can natively double as commands without the need for a separate concept.
When a store containing these events is being used as the primary information store, having some kind of read store can mitigate the necessity for spinning up read models in memory for each query as this can take time and be compute intensive.
Implementing CQRS in this case requires an understanding of how the read data store will be used and what queries will be common. These are important questions to ask early on as the answers will affect your choices moving forward.
For example, these decisions may influence your choice of db (NOSQL, relational, graph), your indexing, and potentially shard keys.
I want to break these questions down a bit more:

• How will the read data store be used?
  This is distinctly different from the question below. You need to understand what requirements you have of the data in this read store. When implementing a separate read store, data is only ever eventually consistent. This means that any operations that rely on the data being fully accurate and up-to-date will not be satisfied. However, for a quick query to demonstrate trends in historic data, there's no problem.
• What queries will be common?
  This will likely result in an array of answers. That's good! That will give you the basis off of which to produce the fields for your state model.