ストーリー

CAP定理

分散システムでは以下の3つを同時に満たすことはできません：

現実の選択

ネットワーク分断（P）は避けられないため、実質的にCかAの選択になります：

ネットワーク分断発生時:

CP選択（整合性優先）:
  Client → Node A [データ更新]
  Node A --✕-- Node B [分断]
  → Node B はエラーを返す（可用性を犠牲）

AP選択（可用性優先）:
  Client → Node A [データ更新]
  Node A --✕-- Node B [分断]
  → Node B は古いデータを返す（整合性を犠牲）

ACID vs BASE

// ACID: 単一DBトランザクション
await db.transaction(async (tx) => {
  const order = await tx.insert(orders).values(orderData);
  await tx.update(inventory).set({ stock: stock - quantity });
  await tx.insert(payments).values(paymentData);
  // 全て原子的に成功 or 失敗
});

// BASE: 結果整合性
// 1. 注文サービスで注文作成（ローカルトランザクション）
await orderDb.insert(orders).values(orderData);
// 2. イベント発行 → 在庫サービスが非同期で処理
await kafka.publish('order.confirmed', orderEvent);
// 3. 最終的に整合する（すぐには整合しない）

整合性モデル

実装パターン

// 読み取り一貫性（Read Your Own Writes）
class OrderService {
  async createAndRead(orderData: OrderInput): Promise<Order> {
    const order = await this.writeDb.create(orderData);
    // 自分が書いたデータはwriteDb（Primary）から読む
    return await this.writeDb.findById(order.id);
    // 他人のデータはreadDb（Replica）から読んでOK
  }
}

2PC（Two-Phase Commit）の限界

Phase 1: Prepare
Coordinator → Participant A: "コミットできる？" → "YES"
Coordinator → Participant B: "コミットできる？" → "YES"

Phase 2: Commit
Coordinator → Participant A: "コミットせよ" → Done
Coordinator → Participant B: "コミットせよ" → Done

結論: マイクロサービスでは2PCは推奨されない。代わりにSagaパターンを使用する。

まとめ

チェックリスト

• CAP 定理の3要素を説明できる
• ACID と BASE の違いを理解した
• 整合性モデルを要件に応じて選択できる
• 2PC の問題点を説明できる

次のステップへ

次は Saga パターンと 2PC の詳細比較を学びます。

推定読了時間: 40分