arch-cqrs

One-line summary

Separate the model used for commands (state-changing operations) from the model used for queries (read-only views). Each can evolve, scale, and persist independently.

When to use this skill

• Read load is dramatically asymmetric with write load — many queries per write, or vice versa.
• Different read use cases need different shapes of the same data (dashboard, search, detail page) — one canonical read model would be a compromise.
• The natural write model (e.g., an aggregate with rich invariants) is awkward to query for views.
• The write side benefits from being event-sourced, but the read side needs fast SQL queries — CQRS is the bridge.

When NOT to use this skill

• Reads and writes are roughly balanced and use the same shape — CQRS is pure overhead.
• The team is unfamiliar with eventual consistency — CQRS introduces it by design.
• The system is small and a normal repository pattern would do — over-engineering.
• "CQRS" used to justify having two database tables for the same data without a real driver — that's just data duplication.

Core content