cqrs-implementation
wshobson/agents
Implement CQRS to separate read and write models for scalable, high-performance architectures.
What is cqrs-implementation?
CQRS (Command Query Responsibility Segregation) separates command (write) and query (read) operations into independent models and handlers. Use it when you need to scale reads independently, optimize query performance, build event-sourced systems, or maintain different schemas for reads and writes.
- Separate command and query APIs for independent scaling
- Implement command handlers that validate and execute state changes
- Create query handlers that retrieve data from optimized read models
- Use event projectors to synchronize read models from write events
- Support eventual consistency between read and write models
- Enable denormalized read models optimized for specific query patterns
How to install cqrs-implementation
npx skills add https://github.com/wshobson/agents --skill cqrs-implementationHow to use cqrs-implementation
- 1.Define your commands representing state-change intents
- 2.Implement command handlers that validate and execute commands, emitting events
- 3.Define your events as immutable records of state changes
- 4.Create query handlers that retrieve data from the read model
- 5.Implement projectors that listen to events and update the read model
- 6.Separate your command API endpoints from query API endpoints
- 7.Configure eventual consistency SLAs acceptable for your use case
Use cases
- High-traffic applications where read and write loads differ significantly
- Event-sourced systems that need to replay state from events
- Complex reporting scenarios requiring denormalized data structures
- Microservices architectures with independent read/write scaling needs
- Systems requiring different data schemas for reads versus writes
- Backend architects designing scalable systems
- Full-stack developers building event-sourced applications
- Teams managing high-traffic read-heavy or write-heavy workloads
- Microservices teams needing independent service scaling
- Database optimization specialists
cqrs-implementation FAQ
Use CQRS when you have different read and write performance requirements, need to scale reads independently, are building event-sourced systems, or require different data models for reads versus writes. For simple applications with uniform read/write patterns, traditional CRUD is simpler.
CQRS uses eventual consistency, meaning read models update asynchronously after events are processed. Define acceptable consistency SLAs for your application and communicate this delay to users where necessary.
No. Command handlers should only validate and execute writes. Queries should only read from the read model. This separation is fundamental to CQRS and prevents coupling between read and write concerns.
Version your events and implement event upcasters that transform old event formats to new ones. This allows you to change schemas without breaking event replay and historical data processing.
No. CQRS and event sourcing are separate patterns. You can use CQRS with traditional databases by having command handlers update the write model and projectors denormalize data into the read model.
Full instructions (SKILL.md)
Source of truth, from wshobson/agents.
name: cqrs-implementation description: Implement Command Query Responsibility Segregation for scalable architectures. Use when separating read and write models, optimizing query performance, or building event-sourced systems.
CQRS Implementation
Comprehensive guide to implementing CQRS (Command Query Responsibility Segregation) patterns.
When to Use This Skill
- Separating read and write concerns
- Scaling reads independently from writes
- Building event-sourced systems
- Optimizing complex query scenarios
- Different read/write data models needed
- High-performance reporting requirements
Core Concepts
1. CQRS Architecture
┌─────────────┐
│ Client │
└──────┬──────┘
│
┌────────────┴────────────┐
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Commands │ │ Queries │
│ API │ │ API │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Command │ │ Query │
│ Handlers │ │ Handlers │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Write │─────────►│ Read │
│ Model │ Events │ Model │
└─────────────┘ └─────────────┘
2. Key Components
| Component | Responsibility |
|---|---|
| Command | Intent to change state |
| Command Handler | Validates and executes commands |
| Event | Record of state change |
| Query | Request for data |
| Query Handler | Retrieves data from read model |
| Projector | Updates read model from events |
Templates and detailed worked examples
Full template library and detailed worked examples live in references/details.md. Read that file when you need the concrete templates.
Best Practices
Do's
- Separate command and query models - Different needs
- Use eventual consistency - Accept propagation delay
- Validate in command handlers - Before state change
- Denormalize read models - Optimize for queries
- Version your events - For schema evolution
Don'ts
- Don't query in commands - Use only for writes
- Don't couple read/write schemas - Independent evolution
- Don't over-engineer - Start simple
- Don't ignore consistency SLAs - Define acceptable lag
Related skills
More from wshobson/agents and the wider catalog.
data-quality-frameworks
Implement data quality validation with Great Expectations, dbt tests, and data contracts for reliable pipelines.
data-storytelling
Transform data into compelling narratives that drive decisions and inspire action.
database-migration
Execute database migrations across ORMs with zero-downtime strategies, data transformation, and rollback procedures.
dataset-curation
Prepare, format, and validate datasets for supervised fine-tuning and preference training.
dbt-transformation-patterns
Master dbt model organization, testing, documentation, and incremental strategies for analytics engineering.
debugging-strategies
Master systematic debugging techniques and root cause analysis to efficiently track down bugs across any codebase.