cqrs-implementation
A pattern for separating read and write data models to improve performance and scalability.
Install
mkdir -p .claude/skills/cqrs-implementation && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/637" && unzip -o skill.zip -d .claude/skills/cqrs-implementation && rm skill.zipInstalls to .claude/skills/cqrs-implementation
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Implement Command Query Responsibility Segregation for scalable architectures. Use when separating read and write models, optimizing query performance, or building event-sourced systems.Key capabilities
- →Separate command and query data models
- →Implement command handlers for state changes
- →Use projectors to update read models from events
- →Define query handlers for data retrieval
- →Version events for schema evolution
How it works
The architecture splits the application into two paths: commands that modify state and queries that retrieve data. Projectors bridge these paths by consuming events from the write model to update the read model.
Inputs & outputs
When to use cqrs-implementation
- →Separate read and write data models
- →Optimize complex query performance
- →Implement event-sourced architecture
About this skill
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
When not to use it
- →For simple applications where read and write models are identical
- →When strong consistency is required without propagation delay
Limitations
- →Requires managing eventual consistency
- →Increases architectural complexity
- →Prohibits querying within command handlers
How it compares
This pattern separates read and write concerns into independent models rather than using a single unified data model for all operations.
Compared to similar skills
cqrs-implementation side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| cqrs-implementation (this skill) | 7 | 2mo | No flags | Advanced |
| database-design | 6 | 6mo | Review | Intermediate |
| database-schema-designer | 6 | 6mo | No flags | Intermediate |
| schema-designer | 1 | 7mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by wshobson
View all by wshobson →You might also like
database-design
davila7
Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases.
database-schema-designer
davila7
Design robust, scalable database schemas for SQL and NoSQL databases. Provides normalization guidelines, indexing strategies, migration patterns, constraint design, and performance optimization. Ensures data integrity, query performance, and maintainable data models.
schema-designer
clidey
Help design database schemas, create tables, and plan data models. Activates when users ask to create tables, design schemas, or model data relationships.
database-architect
sickn33
Expert database architect specializing in data layer design from scratch, technology selection, schema modeling, and scalable database architectures. Masters SQL/NoSQL/TimeSeries database selection, normalization strategies, migration planning, and performance-first design. Handles both greenfield architectures and re-architecture of existing systems. Use PROACTIVELY for database architecture, technology selection, or data modeling decisions.
managing-database-sharding
jeremylongshore
Process use when you need to work with database sharding. This skill provides horizontal sharding strategies with comprehensive guidance and automation. Trigger with phrases like "implement sharding", "shard database", or "distribute data".
orleans
managedcode
Build or review distributed .NET applications with Orleans grains, silos, persistence, streaming, reminders, placement, transactions, serialization, event sourcing, testing, and cloud-native hosting.