ラジオの話題06:成功したか分からない課金、どうする?
今日の話題:①processingの中に隠れる二つの状態 → ②自分のDBをrollbackしたら → ③再試行するか、止めるか。
気になったところから自由に。順番や時間は決めず、話しやすい話題だけ拾って構いません。
1. processingの中に隠れる二つの状態
Section titled “1. processingの中に隠れる二つの状態”話を広げるメモ
- まだ外部APIを呼んでいない。
- 外部で成功したが、自DBへ結果を保存していない。
小ネタ:観測上、区別できない
どちらも自DBにprocessingだけが残る設計では、再起動後に同じ状態に見える。状態名を増やしても、外部効果と記録の間の停止問題が自動で消えるわけではない。
話の芯:状態表示と、外で起きた事実を区別する。
2. 自分のDBをrollbackしたら
Section titled “2. 自分のDBをrollbackしたら”話を広げるメモ
- 外部の課金も取り消されたと言える?
- DB lockを保持しながら待つ利益は?
小ネタ:transactionの境界
自DBのtransactionは、独立した外部APIの効果をそのままrollbackできない。長くlockを持っても、この境界をまたぐ原子性は得られない。
話の芯:どの資源まで一緒に戻せるのか。
3. 再試行するか、止めるか
Section titled “3. 再試行するか、止めるか”話を広げるメモ
- 同じ操作IDで相手へ照会できる?
- 相手が冪等キーも照会も提供しないなら?
小ネタ:at-least-onceとat-most-once
再試行は重複の可能性を、再実行しない選択は未実行のまま失う可能性を持つ。照合不能なら業務の許容する損失を決める必要がある。「exactly-once」と言うときも、どの効果の一度だけなのかを明示する。
話の芯:分からない状態を、勝手に成功・失敗へ丸めない。
最後に一言、話すなら
Section titled “最後に一言、話すなら”「この話を、次に調査や設計をするときどう思い出したいか?」
このメモの材料
Section titled “このメモの材料”既存の学習振り返り教材から話題を選び、AIが小ネタとして再構成しました。説明・設計例と、本人の回答・実測の記録は別です。数値例は記載した仮定に基づくもので、本人の本番実績ではありません。
定義の詳細・前提・一次資料・対象版・確認日は元の教材を参照してください。今回の作成では新しい実験・学習評価は行っていません。