01 / Compositional · Event-backed CQRS
Keep what happened.
Read what you need.
Command Query Responsibility Segregation
Separate write and read responsibilities when they need different models or scaling characteristics. Make the consistency boundary explicit.
Separate responsibilities
Preserve what happened. Build a separate model for the questions you need to answer.
Presentation: ← → to step · Esc to exit
01 / Problem
One model, competing demands.
Recording a business change and answering a question about current state are different jobs. A single model can become difficult to evolve when those needs diverge.
02 / How it works
History in. Current state out.
This scene uses an event-backed implementation: validated commands produce retained events, and a projection turns that history into a queryable view. CQRS itself does not require event sourcing.
03 / Why use it
Give each side room to evolve.
Read models can match specific questions, and read and write workloads can scale independently. Choose this separation when its value justifies the additional moving parts.
04 / Trade-offs
Acknowledged is not yet visible.
Projection lag can leave a query briefly behind a successful write. Failure recovery, projection rebuilds and user expectations need explicit design. A simple CRUD model remains a good choice when this complexity buys little.
Technical reference: Confluent — CQRS. This scene illustrates one implementation; timing and data are simulated.