【要約】AI バッチ生成で「途中まで成功した分の返金」を漏らさない設計 — 独立 DB セッションで失敗を必ず記録する [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
- ・AI APIの失敗時にクレジットが消失する。
- ・例外処理の不備により、成功した分まで巻き戻る。
- ・返金処理自体が失敗した場合、不整合が検知できず、顧客の強い不満に直結する。
// Approach
1.Reserve:
SELECT FOR UPDATEでクレジットを予約。即座にcommitし、AI呼び出し中の行ロックを回避。2.Consume: 各機能ごとに
try/exceptを適用。部分的な成功を許容する設計。3.Partial refund: 失敗件数を集計し、一括返金を実行。
4.Fail-safe: 返金失敗時は、
NullPoolを用いた独立したAsyncSessionでfailed_refundsへ記録。Slack通知も併用。// Result
- ・「返金漏れゼロ」を運用面で担保。
- ・DB書き込み失敗時も、Slackやログからリカバリが可能。
- ・長時間トランザクションによるDBロック問題を解消。
Senior Engineer Insight
> 決済系における「失敗の失敗」への備えは不可欠。コストを払ってでも
NullPoolで独立セッションを作る判断は、整合性重視の現場では極めて合理的。AIのような不確実な外部APIを扱う場合、トランザクション境界の設計がシステムの信頼性を決定づける。運用コストを考慮しても、この三段構えのセーフティネットは実戦投入に値する。