Overview
A single model uses one unified set of classes and one schema for both reading and writing data, while CQRS (Command Query Responsibility Segregation) splits the system into separate write models (commands) and read models (queries) that can use different schemas, storage, or even databases. The choice matters because it trades simplicity and consistency for scalability and query flexibility as read and write demands diverge.
Comparison Diagram
Comparison Table
| Aspect | Single Model | CQRS |
|---|---|---|
| Request entry point | One API/service handles reads and writes through the same code path | Requests are split upfront into command handlers and query handlers |
| Data model shape | One set of classes/entities represents the domain for every operation | Separate write model (rich domain logic) and read model (denormalized, query-optimized) |
| Write path | Write validates and persists directly to the shared schema | Command handler validates, applies business rules, persists to the write store |
| Read path | Read queries the same schema writes use, often requiring joins | Query handler reads from a precomputed, often denormalized read store |
| Sync between models | Not applicable — there is only one model, so no sync is needed | Read store is updated via events or projections after each write, introducing lag |
| Consistency guarantee | Strong consistency by default since reads see writes immediately | Eventual consistency between write and read sides unless engineered otherwise |
| Scaling behavior | Read and write load scale together since they share infrastructure | Read and write sides scale independently to match different load profiles |
| Operational complexity | Low — one schema, one deployment, one mental model to maintain | Higher — multiple stores, projection/event pipelines, and eventual-consistency debugging |
Key Differences
- Single model keeps one schema for everything; CQRS splits into a write model and a read model
- CQRS trades immediate consistency for eventual consistency via projections or events
- Single model is simpler to reason about; CQRS adds operational overhead from syncing multiple stores
- CQRS enables independent scaling of reads and writes; single model scales them together
- Query flexibility is higher in CQRS since read models can be shaped per use case
When to Use Each
Single Model
- CRUD-heavy applications: Standard CRUD apps benefit from the simplicity of one model with no sync logic to maintain.
- Small to mid-size teams: A single model reduces cognitive load and infrastructure when a team lacks the bandwidth to manage eventual consistency.
- Strong consistency requirements: When reads must always reflect the latest write immediately, a single model avoids replication lag entirely.
CQRS
- Read/write ratio imbalance: When reads vastly outnumber writes (or vice versa), CQRS lets you scale and optimize each side independently.
- Complex reporting needs: Denormalized read models let you serve dashboards and search views without expensive joins on the write schema.
- Event-sourced domains: CQRS pairs naturally with event sourcing, where the write side appends events and read models are rebuilt as projections.