Analyze the trade-offs among consistency, availability, and scalability in CQRS to support design decisions.
Evaluation Axes Based on the CAP Theorem
The reason CQRS adopts consistency and availability as important evaluation axes is based on the CAP theorem.
In distributed systems, when network partitions or failures occur, a trade-off between consistency and availability is unavoidable. CQRS skillfully leverages this trade-off.
| Model | Characteristic Emphasized | Reason |
|---|---|---|
| Write Model | Consistency | Because it makes decisions and calculations based on the current state |
| Read Model | Availability | Because it is often sufficient even if not the latest state |
Through this separation, rather than pursuing consistency and availability simultaneously, it becomes possible to select the optimal strategy for each model.
Two Forms of CQRS
Simple CQRS (without Event Sourcing)
- Guarantees the same consistency as non-CQRS-based systems
- Logical separation of read and write models
- Can be implemented even on existing RDBMS
CQRS + Event Sourcing (CQRS/ES)
- Independently controls consistency levels for the read model and the write model
- Write model: strong consistency
- Read model: eventual consistency
- System flexibility is greatly improved
Three Evaluation Axes
1. Impact on Consistency
Write Model: Because it makes decisions and calculations based on the current state of the system,strong consistencyis required.
Read Model: Because it is often sufficient even if not the latest state,eventual consistencyis applied. This can be expected to improve performance and response speed.
| Form | Consistency of the Write Model | Consistency of the Read Model |
|---|---|---|
| Simple CQRS | Equivalent to conventional | Equivalent to conventional |
| CQRS/ES | Strong consistency | Eventual consistency |
2. Impact on Availability
In CQRS/ES, while the write model requires strong consistency, the eventual consistency of the read model enables high availability.
Behavior During Failures:
- Even if writes are temporarily suspended, read operations can continue
- A full system downtime can be avoided
- Through caching and replication functions, service availability is maintained even when failures occur
3. Impact on Scalability
By separating the read model and the write model,scale independentlycan be made to do so.
Read Model:
- Many applications are read-heavy
- Achieve high scalability by leveraging caching and replication
- Different microservices host different projections, specialized for specific queries
Write Model:
- Leverage sharding and other distributed techniques
- Independent scaling according to write load
Essential Similarity to RDB Configuration
The trade-offs of CQRS are similar to those of RDB1 writer / N read replica configurationis essentially the same.
| Perspective | CQRS/ES | RDB 1W/NR configuration |
|---|---|---|
| Write | Strong consistency | Write to master |
| Read | Eventual consistency | Read from replica |
| During failure | Reads can continue | Reads can continue on replica |
| Scaling | Independent reads and writes | Scale reads by adding replicas |
Both involve trade-offs based on the CAP theorem, so the same way of thinking applies. Understanding this similarity can lower the barrier to adopting CQRS.
Design Decision Flow
Decision to Adopt CQRS
1. 読み込みと書き込みの負荷特性が異なるか？
→ No: シンプルなCRUDで十分な可能性
→ Yes: 次へ
2. 読み込みと書き込みで異なるモデルが有利か？
→ No: 単一モデルで対応可能
→ Yes: シンプルなCQRSを検討 → 次へ
3. 読み込みモデルで結果整合性を許容できるか？
→ No: シンプルなCQRS（同一DB）を検討
→ Yes: CQRS/ESを検討 → 次へ
4. 高い可用性・スケーラビリティが要求されるか？
→ No: シンプルなCQRSで十分
→ Yes: CQRS/ES + 読み書きモデルの物理分離を検討
Decision on Whether to Use Event Sourcing Together
| Requirement | ES not needed | Consider ES |
|---|---|---|
| Consistency level | Same for reads and writes is acceptable | Independent control of reads and writes is needed |
| Audit trail | Not needed | Needed |
| Reproducing state along the time axis | Not needed | Needed |
| Complex projections | 1-2 types | Many views are needed |
Decision on Accepting Eventual Consistency
| Domain characteristic | Eventual consistency | Strong consistency |
|---|---|---|
| SNS feed display | Acceptable | Not needed |
| Product catalog search | Acceptable | Not needed |
| Balance of financial transactions | Not acceptable | Required |
| Inventory allocation decision | Not acceptable | Required |
| Dashboard aggregation | Acceptable | Not needed |
| Payment processing | Not acceptable | Required |
Judgment criterion: Does a delay of seconds to minutes cause business damage?
Review Checklist
Architecture Decision
- Have you analyzed the load characteristics of reads and writes?
- Have you clarified the reason CQRS is needed (why simple CRUD is insufficient)?
- Have you determined whether event sourcing is necessary?
Consistency Design
- Is strong consistency guaranteed in the write model?
- Does the eventual consistency of the read model match the business requirements?
- Has the allowable delay range for eventual consistency been defined?
Availability Design
- Is the design such that reads can continue during a write failure?
- Is the cache and replication strategy for the read model defined?
- Is the fallback strategy in the event of a failure clear?
Scalability Design
- Can the read model and write model scale independently?
- Is there a scaling strategy for read load (replication, caching, etc.)?
- Is there a scaling strategy for write load (sharding, etc.)?
- Is a projection strategy (such as specialized views per microservice) defined?
Related Skills (Recommended for Concurrent Reading)
When using this skill, also refer to the following skills:
cqrs-to-event-sourcing: Why CQRS necessarily requires event sourcingcqrs-aggregate-modeling: The impact of CQRS/ES on aggregate boundary definition and modelingaggregate-design: Aggregate design rules before applying CQRS