---
name: cqrs-tradeoffs
description: >
  CQRS（Command Query Responsibility Segregation）における一貫性・可用性・スケーラビリティの
  トレードオフ分析と設計判断を支援する。CAP定理に基づくCQRSの評価軸、イベントソーシングとの
  組み合わせによる影響、読み書きモデルの分離戦略を提供する。アーキテクチャ設計、技術選定、
  既存システムのCQRS導入検討時に使用。
  対象言語: 言語非依存（Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて）。
  トリガー：「CQRSを採用すべきか」「読み書き分離の設計」「結果整合性の判断」
  「イベントソーシングを組み合わせるべきか」「CQRSのトレードオフ」「CQRSの可用性」
  「CQRSのスケーラビリティ」「書き込みモデルと読み込みモデルの分離」
  といったCQRS設計判断関連リクエストで起動。
---

# CQRSトレードオフガイド

CQRSにおける一貫性・可用性・スケーラビリティのトレードオフを分析し、設計判断を支援する。

## CAP定理に基づく評価軸

CQRSが一貫性と可用性を重要な評価軸として採用する理由は、CAP定理に基づいている。

分散システムでは、ネットワークの分断や障害が発生した場合、一貫性と可用性の間でトレードオフが生じることが避けられない。CQRSはこのトレードオフを巧みに活用する。

| モデル | 重視する特性 | 理由 |
|--------|-------------|------|
| 書き込みモデル | **一貫性** | 現在の状態に基づく意思決定・計算を行うため |
| 読み込みモデル | **可用性** | 最新の状態でなくても十分な場合が多いため |

この分離により、一貫性と可用性を同時に追求するのではなく、各モデルで最適な戦略を選択できる。

## CQRSの2つの形態

### シンプルなCQRS（イベントソーシングなし）

- 非CQRSベースのシステムと同様の一貫性を保証
- 読み書きモデルの論理的な分離
- 既存のRDBMS上でも実装可能

### CQRS + イベントソーシング（CQRS/ES）

- 読み込みモデルと書き込みモデルで一貫性レベルを独立して制御
- 書き込みモデル: 強い一貫性
- 読み込みモデル: 結果整合性
- システムの柔軟性が大幅に向上

## 3つの評価軸

### 1. 一貫性への影響

**書き込みモデル**: システムの現在の状態に基づいて意思決定や計算を行うため、**強い一貫性**が求められる。

**読み込みモデル**: 最新の状態ではなくても十分な場合が多く、**結果整合性**が適用される。これにより、パフォーマンスと応答速度の向上が期待できる。

| 形態 | 書き込みモデルの一貫性 | 読み込みモデルの一貫性 |
|------|----------------------|----------------------|
| シンプルなCQRS | 従来と同等 | 従来と同等 |
| CQRS/ES | 強い一貫性 | 結果整合性 |

### 2. 可用性への影響

CQRS/ESでは、書き込みモデルが強い一貫性を必要とする一方、読み込みモデルの結果整合性により高い可用性を実現できる。

**障害時の振る舞い**:
- 書き込みを一時停止しても、読み込み操作は継続可能
- システムの全面的なダウンを回避できる
- キャッシュやレプリケーション機能により、障害発生時でもサービスの可用性を維持

### 3. スケーラビリティへの影響

読み込みモデルと書き込みモデルを分離して**独立にスケール**させることができる。

**読み込みモデル**:
- 多くのアプリケーションが読み込み重視
- キャッシュやレプリケーションを活用して高いスケーラビリティを実現
- 異なるマイクロサービスが異なるプロジェクションをホストし、特定のクエリに特化

**書き込みモデル**:
- シャーディングや他の分散技術を活用
- 書き込み負荷に応じた独立スケーリング

## RDB構成との本質的類似性

CQRSのトレードオフは、RDBの**1台ライター / N台リードレプリカ構成**と本質的に同じである。

| 観点 | CQRS/ES | RDB 1W/NR構成 |
|------|---------|---------------|
| 書き込み | 強い一貫性 | マスターへの書き込み |
| 読み込み | 結果整合性 | レプリカからの読み込み |
| 障害時 | 読み込み継続可 | レプリカで読み込み継続可 |
| スケーリング | 読み書き独立 | レプリカ追加で読み込みスケール |

どちらもCAP定理に基づくトレードオフが生じるため、同じ考え方が適用される。この類似性を理解することで、CQRSの導入ハードルを下げることができる。

## 設計判断フロー

### CQRSの採用判断

```
1. 読み込みと書き込みの負荷特性が異なるか？
   → No: シンプルなCRUDで十分な可能性
   → Yes: 次へ

2. 読み込みと書き込みで異なるモデルが有利か？
   → No: 単一モデルで対応可能
   → Yes: シンプルなCQRSを検討 → 次へ

3. 読み込みモデルで結果整合性を許容できるか？
   → No: シンプルなCQRS（同一DB）を検討
   → Yes: CQRS/ESを検討 → 次へ

4. 高い可用性・スケーラビリティが要求されるか？
   → No: シンプルなCQRSで十分
   → Yes: CQRS/ES + 読み書きモデルの物理分離を検討
```

### イベントソーシング併用の判断

| 要件 | ES不要 | ES検討 |
|------|--------|--------|
| 一貫性レベル | 読み書き同一で可 | 読み書きで独立制御が必要 |
| 監査証跡 | 不要 | 必要 |
| 時間軸での状態再現 | 不要 | 必要 |
| 複雑なプロジェクション | 1〜2種類 | 多数のビューが必要 |

### 結果整合性の許容判断

| ドメイン特性 | 結果整合性 | 強い一貫性 |
|-------------|-----------|-----------|
| SNSフィード表示 | 許容可 | 不要 |
| 商品カタログ検索 | 許容可 | 不要 |
| 金融取引の残高 | 不可 | 必須 |
| 在庫の引当判定 | 不可 | 必須 |
| ダッシュボード集計 | 許容可 | 不要 |
| 決済処理 | 不可 | 必須 |

**判断基準**: 数秒〜数分の遅延がビジネス上の損害を生むか？

## レビューチェックリスト

### アーキテクチャ判断

- [ ] 読み書きの負荷特性を分析したか
- [ ] CQRSが必要な理由（シンプルなCRUDでは不十分な理由）を明確にしたか
- [ ] イベントソーシングの要否を判断したか

### 一貫性設計

- [ ] 書き込みモデルで強い一貫性が担保されているか
- [ ] 読み込みモデルの結果整合性がビジネス要件に合致しているか
- [ ] 結果整合性の遅延許容範囲を定義したか

### 可用性設計

- [ ] 書き込み障害時に読み込みが継続できる設計か
- [ ] 読み込みモデルのキャッシュ・レプリケーション戦略が定義されているか
- [ ] 障害発生時のフォールバック戦略が明確か

### スケーラビリティ設計

- [ ] 読み込みモデルと書き込みモデルが独立にスケール可能か
- [ ] 読み込み負荷に対するスケーリング戦略（レプリケーション、キャッシュ等）があるか
- [ ] 書き込み負荷に対するスケーリング戦略（シャーディング等）があるか
- [ ] プロジェクション戦略（マイクロサービスごとの特化ビュー等）が定義されているか

## 関連スキル（併読推奨）
このスキルを使用する際は、以下のスキルも併せて参照すること：
- `cqrs-to-event-sourcing`: CQRSがイベントソーシングを必然的に要求する理由
- `cqrs-aggregate-modeling`: CQRS/ESが集約の境界定義とモデリングに与える影響
- `aggregate-design`: CQRS適用前の集約設計ルール