サービス間のデータ整合性が保証されているか？¶
Type: Structure
Category: イベント・非同期処理
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
マイクロサービスや疎結合なシステムでは一貫性の保証が難しくなるため、設計段階で「いつ整合すべきか」を明確にする必要がある
例¶
- イベント駆動 + 結果整合性 な整合戦略を採用する
- あるステータスの更新をTaskサービス、Documentサービスの双方向で同期するのではなく、Taskサービスからのみ更新しDocumentサービスは購読するのみなどの一方向のデータフローで整合性を確保する
- 更新後イベント送信＋受信側バリデーションにより不整合を防止する
よくある失敗例¶
- 双方向更新でデータの整合が取れず、最新の情報が不明になる
- 処理順序が保証されておらず、古いイベントで上書きされる
- レプリカが遅延し、読み取りに誤差が出る
FAQ¶
Q. 結果整合性で本当に大丈夫？
A. ケースバイケースだが、多くの業務は即時一致よりも「ある程度の時間内で整合」で十分なことが多い。それを考え定義してドキュメントに明記するのが重要
Q. 双方向同期はやめるべき？
A. 原則やめるべき。一方通行の更新フローにしないと同期地獄になるので