バッチ・API・外部連携の失敗を設計する

このレッスンの到達目標

部分失敗と再送を、運用で回復できる構造にする。

音声とインタラクティブ図解で学ぶ音声を再生すると、下のインタラクティブ図解と本文の段落ハイライトが連動して動きます。

TRANSACTION & IDEMPOTENCY LAB · AUDIO & INTERACTIVE

DBトランザクション境界・外部連携タイムアウト・冪等再送ラボ

明細更新途中のエラーや、会計連携APIの応答消失時に「データ不整合」や「二重計上」がなぜ起きるのか、パケットアニメーションで検証します。

データ更新と外部境界の挙動1. トランザクションなし（部分失敗）

受注明細を更新した直後にエラーが発生し、受注ヘッダー合計が旧金額のまま残った状態です。

設計・移行・運用の要点DB内部で明細と合計が300円不一致

DBのロールバックだけでは外部送信は取り消せません。連携IDによる冪等性、処理済み照会、照合（件数・金額）をセットで設計します。

連携には入力形式、識別子、重複判定、結果照会、エラー応答を定めます。同じ要求の再送があり得る前提で、冪等性の範囲と保証期間、処理済み結果の扱いを確認します。通信失敗が処理失敗とは限りません。

DB更新と送信の間で失敗する場合、送信待ちの記録や再送の管理などを検討します。採用方式に応じて保証できることとできないことを明示し、外部先との契約や照合方法も確認します。技術名だけで解決したことにしません。

バッチは対象の抽出条件、処理単位、進行記録、途中再開、二重実行防止を設計します。部分成功した場合にどこから再実行できるか、失敗データをどう扱うか、運用者が判断するためのログと手順を定めます。

処理時間、監視、復旧、監査の条件を設計に反映します。再実行を操作できる人と承認者、照合結果の確認者を決めます。設計した回復方法は検証環境で試し、手順だけを書いて完了としないでください。

読了記録と習熟度の確認は別です。