CQRS separates operations that change state from operations that retrieve it. In a profile system, ProfileService can own updates, persist profile records, and publish change events, while other services build read models suited to their needs. section 7.1.3
Figure 7.10 Different object models are responsible for writing and reading the data.
Use the contrasting object models to see that write and read models can differ conceptually, physically, and in their persistence mechanisms. section 7.1.3
CQRS is most useful when the read and write sides have materially different demands:
- Use it when querying requires a much more complex model than updating. section 7.1.3
- Use it when reads greatly outnumber writes and require different scaling strategies. section 7.1.3
- Avoid adding it to primarily CRUD-oriented services when the separation creates unnecessary overhead. section 7.1.3
- Choose the separation boundary deliberately: CQRS may remain within one service or span multiple microservices. section 7.1.3
Figure 7.11 Implementing the CQRS pattern with Kafka. Here OrderService is a command, which updates orders, and the other services are query services. Query services may have pretransformed denormalized data.
Use the Kafka topology to trace a command-side service emitting events and multiple query services maintaining differently shaped, possibly denormalized data. section 7.1.3
Kafka fits CQRS by carrying events from command logic to independent query services. Those services can transform the events into read-oriented data. CQRS is also commonly combined with event sourcing, while snapshotting can improve consumer restoration performance. section 7.1.3 section 7.6
