サービス間では、通常強い一貫性を結果整合性と交換し、CQRSとevent sourcingに頼ってそれを実用的で正確にします。
変更後、レプリカは瞬時ではなく「すぐに」収束します。ほとんどのビジネスフロー（在庫数は1秒遅れることがある）では許容可能ですが、一部（銀行残高チェック）では許容できません。
write modelを1つ以上のread modelsから分離します。
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
読み取りは書き込みとは独立してスケール及び再構成されます。read modelはイベントから更新されるため、結果整合性があります。
現在の状態だけでなく、イベントのシーケンスをトゥルース・ソースとして保存します。現在の状態はイベント上の折り畳みです。
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は、結果整合性を信頼でき、監査可能にするためのツールを提供します — しかし、それぞれが実際の複雑さを追加するため、デフォルトではなく、慎重に適用します。