🙌
サービス間のデータ整合性が保証されているか？
サービス間のデータ整合性が保証されているか？
背景・概要
マイクロサービスや疎結合なシステムでは一貫性の保証が難しくなるため、設計段階で「いつ整合すべきか」を明確にする必要がある
例
- イベント駆動 + 結果整合性 な整合戦略を採用する
- あるステータスの更新をTaskサービス、Documentサービスの双方向で同期するのではなく、Taskサービスからのみ更新しDocumentサービスは購読するのみなどの一方向のデータフローで整合性を確保する
- 更新後イベント送信＋受信側バリデーションにより不整合を防止する
よくある失敗例
- 双方向更新でデータの整合が取れず、最新の情報が不明になる
- 処理順序が保証されておらず、古いイベントで上書きされる
- レプリカが遅延し、読み取りに誤差が出る
FAQ
Q. 結果整合性で本当に大丈夫？
A. ケースバイケースだが、多くの業務は即時一致よりも「ある程度の時間内で整合」で十分なことが多い。それを考え定義してドキュメントに明記するのが重要
Q. 双方向同期はやめるべき？
A. 原則やめるべき。一方通行の更新フローにしないと同期地獄になるので
関連観点
- 一貫性を担保するための分散トランザクションの必要性が整理されているか？
- 非同期イベントの遅延やリトライ処理の影響を考慮した設計になっているか？
- 依存する外部サービスの障害時の影響を考慮しているか？
- 非同期処理と同期処理の適用範囲が適切か？
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🔁 イベント・非同期処理
レベル：Structure（構造・原則・責務整理レベル）
推奨読者：設計初心者 / 設計中のチーム / レビュワー
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion