はじめに
このエントリは、初挑戦カレンダー Advent Calendar 2025 の 3日目記事です。
https://qiita.com/advent-calendar/2025/silvia
今年、Twitterで何か主張したかったことを拾いながら記事を書いていきます。
本文
基本、DB関連処理というものは、処理の単位でトランザクションを作り、処理が成功したら全ての変更を実行、失敗したら全ての処理をなかったことにするというのが鉄則である。
通常であればDB関連処理はバックエンドが担当し、トランザクションの範囲を決める事で比較的容易に実現できる。
今回問題となったのは、BFF（Backend for Frontend）を立てた場合であった。
何故BFFが必要になったのかというと、色々なシステムをマイクロサービス化する方式で、
各種サービスの連携はBFFで行うという基本方針が取られたからである。
もうお分かりだろうが、他システムで処理失敗する可能性がある以上、データ整合性を担保するには、自サービスか他サービスのどちらかで、もう一方のサービス失敗時のロールバックをする必要があった。
データの登録処理を行った場合は、登録したデータを削除しなければならないし、
逆に削除を行った場合は削除をなかったことにしなければならない。
サーバのトランザクション内で行うのは非常に容易いが、一度サーバを出てしまった場合は
ロールバックが難しいのだ。
なので、汎用的なロールバック処理を行うAPIを作ったらいいのではないかと考えた。
DBに対する変更が行われた際、その前の状態を保持しておいて、キーを発行し、返す。
そのキーをロールバック用のAPIに投げると、保存しておいた前の状態に戻るというAPIだ。
BFFでサービス間連携を行う場合、とても有用な機能に思えた。
が、結局作らなかった。
理由はいくつかあり、単純に工数が捻出できなかったのがまず一つ。
次に、設計がなかなか難しかったのが挙げられる。
このロールバックAPI、当然だが失敗する可能性を捨てる事はできない。
では失敗した時、どういう挙動をするのが良いのか？
これが失敗したという事は、当然データ不整合が発生していることになる。
データ不整合はシステムに致命的なダメージを与える可能性があり、かなり緊急度の高い通知を飛ばす必要がある。しかも管理者に向けて。
また、このロールバックAPIは汎用化していることがメリットとなるので、
何のデータが不整合を起こしたのかはすぐに判断できない。
そのため、このAPIが失敗した時点で緊急性が高い状況となり、運用含めてきちんと設計する必要があり、一開発者の思いつきで実装するにはかなり重い機能だったためである。
最後に、ロールバックAPIが欲しいと思った機能が、そこまで厳密にデータの整合性を必要としなかった点である。
一つのデータにおいて整合性が取れなくなっても、システムが落ちるという事はなく、ただ使えないデータが一つできあがるだけだったため、必要ないという判断となった。
残念。
今回、ロールバックAPIを作る事はなかったが、きちんと設計できていればBFFのあるサービス設計としてはかなり強力な機能となると思う。
もしどうしても必要になれば作ると思うので、そうならないかなあと思っている。