要約

結果整合性の課題と対処法についていくつかのパターンを紹介

前提

分散システムではモノリスで実現できていた強いトランザクションは実現できない。なので、最終的に整合させる結果整合性という考えを受け入れる

結果整合性の課題

最終的に整合する状態になるまでの間は不整合な状態が存在する
その不整合な状態のときをどのように受け入れて対応するか検討必要

対策いろいろ

※AI使わないといいながらCopilotにまとめてもらいました。。

対処法	概要	実例	メリット	デメリット
イベントスキーマの工夫	イベントに必要な情報を含めて、他サービスへの依存を減らす	在庫イベントに全サイズの在庫情報を含めて通知	外部呼び出し不要で高速・高可用性消費者側の実装が簡単	イベントサイズが大きくなる情報が取得できない場合は複雑化
ドメイン境界の適用	サービスを明確なドメインに分割し、整合性の問題を内部で閉じ込める	在庫管理と通知サービスを別ドメインに分離	境界内で整合性を担保できる外部への影響を最小化	境界間の連携が複雑化処理時間が増加する可能性
イベントバージョン管理	イベントにバージョンやタイムスタンプを持たせ、整合性の判定に使う	APIのレスポンスとイベントのバージョンを比較して再試行判断	実装が簡単整合性の遅延を検知しやすい	再試行の失敗時に補償処理が必要パフォーマンスに影響
状態の保存（ローカルキャッシュ）	他サービスの情報をローカルに保存して参照	通知サービスが在庫情報を自前で保持	外部依存がなく高可用性高速なレスポンス	ストレージコスト増データの同期が必要冗長なデータ管理
メモリへのバッファリング	一時的にイベント情報をメモリに保持して参照	通知サービスが在庫イベントを一定時間メモリに保持	高速処理永続化不要で管理が簡単	大規模データには不向きメモリ消費が増加
エンドツーエンド原則の活用	中間サービスの整合性を犠牲にし、最終的なビジネスルールで整合性を担保	商品購入時に在庫を最終確認して注文処理	柔軟な設計が可能中間サービスの負荷軽減	最終処理に同期が必要 UIと整合性のズレが発生する可能性
高速処理による見かけ上の整合性	処理速度を上げて整合性のズレ時間を短縮	Kafka + Kubernetes + Prometheus によるオートスケーリング	ユーザーにとっては整合性が保たれているように見える UX向上	高速化のためのインフラ整備が必要ピーク時の対応が難しい場合もある

Claudeで生成した画像

イベントスキーマの工夫 - 全サイズ情報を含めた在庫イベントの流れ

ドメイン境界の適用 - 在庫管理と通知の明確な分離

イベントバージョン管理 - バージョン比較による整合性判定

状態の保存 - ローカルDBによる高速アクセス

メモリバッファリング - TTL付きメモリキャッシュ

エンドツーエンド原則 - 購入時の最終確認フロー

高速処理 - Kafka + Kubernetes + Prometheusの構成

おわりに

結果整合性を実現する方法について意外とたくさんの選択肢があってメモメモでした。方法論：ドメイン境界の適用がよくわかんなかったので３章と４章を読んでから改めて５章を見たいと思います！