CQRS (Command Query Responsibility Segregation)
Splitting a system into a write side that changes data and a separate read side shaped for queries, kept in sync by events.
Commands go through the domain model, which checks the rules and saves the change together with an event in one transaction (transactional outbox). A relay publishes the event, and a projection updates a read database built for the screens and reports that need it; queries never touch the domain model. The price is a second model to maintain and a read side that lags behind writes, so a user may not see their own change at once (eventual consistency). CQRS does not require event sourcing; the two are often confused.
Related terms
- Event sourcing: Storing every change as an event in an append-only log and rebuilding current state by replaying it, instead of storing only the latest state.
- Transactional outbox: Saving an event to an outbox table in the same database transaction as the change itself, then publishing it to the broker separately.
- Eventual consistency: A guarantee that copies of data will agree once updates stop arriving, but may briefly show different values in the meantime.
- Database per service: Each service owns its data and no other service reads its tables directly; the others go through its API or its events.
