概要
マイクロサービスを採用している某社には以下のサービスがある
・決済サービス
・アカウントサービス
決済サービスでは、決済代行での決済時には事業者に紐づくshopIDを
アカウントサービスから取得する必要がある。
問題
ある日、A社がB社に吸収合併されると連絡が来た。
・A社-shopID_A
・B社-shopID_B
それに伴い、アカウントサービスチームから以下変更をするが問題ないか確認が来た。
A社-shopID_Aを
→B社_A支店-shopID_B
に更新したい。
この変更は、金額訂正をする場合に問題となる。なぜなら金額訂正には初回決済時のshopIDをリクエストする必要があるからだ。
決済サービスではA社という情報は記録されているが、どのshopIDだったかは記録されていない。
解決案
初案
決済サービス側で新規決済時にどのshopIDが使われたか保存し、
金額訂正時にはそのshopIDを利用する。
初案に対する課題
・アカウントサービスで管理していた情報が決済サービスに侵食
・shopID保存対応以前のshopIDは記録されていない状態のため、金額訂正に失敗する
・処理の複雑化
新案
レコードの更新ではなく追加
→金額訂正ではB社をリクエストし、新規決済ではB社_A支店をリクエストする
メリット
・初案の課題は払拭
・決済サービス側の対応不要
デメリット
アカウントサービス側でレコード管理の複雑化
→案：
・versionカラム追加
・expired_atカラムを追加（金額訂正には訂正期限があるため、その期間を入れておく）
今回だとB社_A支店を追加した時点でA社のexpired_atを6ヶ月後に設定。
まとめ
今回の話は広い意味でバーション管理です。
いろんなところで使える。