予約システムと
ゴルフソフトウェア・システム工学
あとで読む保存した記事へ →
まず答え
あります。予約システムと会員システムが別々にデータを持ち、更新を後から同期する設計では、反映までの時間差によって同じ利用者の住所・会員区分・連絡先などが一時的に違って見えることがあります。同期失敗が残ると、一時的ではなく不整合として残ることもあります。
詳しい解説
予約システムと会員システムが別々のデータベースやサービスとして動いている場合、片方で情報を更新しても、もう片方へ同時に反映されるとは限りません。
例えば会員システムで電話番号を変更し、その変更を数秒後・数分後に予約システムへ送る仕組みなら、その間は会員画面では新しい番号、予約画面では古い番号という状態が起こり得ます。AWSの分散システム資料でも、別サービス間のリアルタイム同期は難しい場合があり、更新の伝播に時間差がある「結果的整合性」では古い値が一時的に読まれることがあると説明されています。
さらに、通信エラーや同期処理の失敗、同じ利用者を別IDとして登録した状態があると、時間がたっても自動では一致しないことがあります。つまり「少し待てば必ず直る」とは限りません。
運用では、まずどちらを正本にするかを項目ごとに決めます。例えば氏名・住所・会員区分は会員システムを正本、予約日時は予約システムを正本、といった形です。そのうえで共通の会員IDを使い、更新時刻や版番号を持たせ、失敗した同期を再送し、定期的に両システムの差分を照合します。
したがって、同じ利用者の情報が食い違ったときは、単純な入力ミスだけでなく、どのシステムが正本か、最終更新時刻、同期処理の成否、利用者IDの対応を順に確認するのが適切です。