activatorパターン

オレオレデザインパターン

解決したい課題

DBMSのトランザクション機能が使えない（例：マイクロサービスをまたぐなど）場合に読み取り一貫性を実現する

設計

例えば携帯電話で月の途中でプランを変えた（普通のプランから、Youtubeの通信をカウントしないプラン）場合

ユーザー -> 契約管理システム: プレン変更申し込み
契約管理システム -> 契約管理システム: 新プラン契約を作成（新プランはまだ他システムから参照できない）
契約管理システム -> 通信量集計システム: Youtubeを除外した通信量を集計（重い処理、Cloud DataFlowとかの分散処理とかで実行）
通信量集計システム --> 契約管理システム: activate（ここで他システムから新プランが参照できるようになる）

この例だと重い処理が一つだけど、重い処理を複数並列で走らせなくてはならない時はactivate処理を発行するところを別システムに切り出したりできる。

基本的にはRDBMSでデータを管理すればactivatorを作り込まなくていいので楽。重い処理が時間がかかってトランザクションの長さが他の処理に影響を及ぼす場合に検討すればいいと思う。

あとは、RDBMSで読み取り一貫性を担保するのと違って、未activateのデータも他システムに公開できる利点はあるっちゃあるが、それを本当に利点と言っていいかどうかは個人的には疑問