| name | cqrs-tradeoffs |
| description | Use when evaluating whether CQRS is worth adopting, especially tradeoffs among consistency, availability, scalability, operational complexity, and event sourcing. Trigger for read/write separation decisions, eventual consistency concerns, CQRS architecture review, or choosing between a unified model and CQRS. |
CQRS Tradeoffs
CQRS buys independent read/write models at the cost of more moving parts and explicit consistency choices.
Decision Frame
-
Identify the forces: read scale, write contention, model complexity, audit needs, team maturity, and latency tolerance.
-
Decide which consistency guarantees are required for commands and which can be eventual in reads.
-
Check whether separate read models remove real complexity or just duplicate code.
-
Choose the smallest pattern: unified model, CQRS without ES, CQRS with outbox, or event-sourced CQRS.
Tradeoffs
-
Benefits: optimized reads, simpler command invariants, independent scaling, better audit/projection options.
-
Costs: projection lag, more tests, operational monitoring, replay tooling, schema evolution, and debugging complexity.
-
Red flags: low traffic, simple CRUD, no contention, no audit need, or a team that cannot operate async pipelines.
Detailed Reference
For non-trivial implementation, review, or refactoring work, read references/details.md before giving final guidance. It contains the detailed rules, examples, smells, and migration notes that do not belong in the short invocation body.
Output
Return a recommendation, rejected alternatives, consistency model, migration path, and operational prerequisites.
