イベント・ソーシング、CQRS、eventual consistencyを使用してサービス間の一貫性を実現するにはどうしますか？

Question

IT Interview Practice · Accepted Answer

サービス間では、通常**強い**一貫性を**結果整合性**と交換し、**CQRS**と**event sourcing**に頼ってそれを実用的で正確にします。

## 結果整合性

変更後、レプリカは瞬時ではなく「すぐに」収束します。ほとんどのビジネスフロー（在庫数は1秒遅れることがある）では許容可能ですが、一部（銀行残高チェック）では許容できません。

## CQRS（Command Query Responsibility Segregation）

**write model**を1つ以上の**read models**から分離します。

```text
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
```

読み取りは書き込みとは独立してスケール及び再構成されます。read modelはイベントから更新されるため、結果整合性があります。

## Event sourcing

現在の状態だけでなく、**イベントのシーケンス**をトゥルース・ソースとして保存します。現在の状態はイベント上の折り畳みです。

```text
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
```

## トレードオフ

| 手法 | 利点 | コスト |
|---|---|---|
| 結果整合性 | 可用性、スケーラビリティ | 古い読み取り、競合 |
| CQRS | 読み取り/書き込みスケーラビリティ | 2つのモデルを同期させる必要がある |
| Event sourcing | 監査、リプレイ、履歴 | スキーマ/イベント進化、複雑性 |

## 落とし穴

event sourcingをどこにでも採用しないでください — 強力ですが重量です。監査/履歴が本当に重要な場所で使用します。

## なぜ重要なのか

分散システムは強い一貫性、可用性、分割耐性をすべて同時に持つことはできないため、シニア設計は結果整合性が許容できる場所を選択することです。

CQRSとevent sourcingは、結果整合性を信頼でき、監査可能にするためのツールを提供します — しかし、それぞれが実際の複雑さを追加するため、デフォルトではなく、慎重に適用します。

手法	利点	コスト
結果整合性	可用性、スケーラビリティ	古い読み取り、競合
CQRS	読み取り/書き込みスケーラビリティ	2つのモデルを同期させる必要がある
Event sourcing	監査、リプレイ、履歴	スキーマ/イベント進化、複雑性

結果整合性

CQRS（Command Query Responsibility Segregation）

Event sourcing

トレードオフ

落とし穴

なぜ重要なのか

関連する質問