コードを読み、データ更新を追う

このレッスンの到達目標

入力から保存までと、失敗時の整合性を説明する。

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

TRANSACTION & IDEMPOTENCY LAB · AUDIO & INTERACTIVE

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

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

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

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

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

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

入力チェック、業務計算、DB更新、応答の順をたどり、どこで何を保証するか確認します。画面上のチェックだけでは、別のAPIやバッチ経由の更新を保証できません。

受注明細と受注合計の更新など、一緒に成功すべき処理を見つけます。トランザクションは関連する更新をまとめる仕組みですが、範囲や分離レベル、外部サービスとの境界は別に設計が必要です。

二人が同じ在庫を更新する場面、応答がなく同じ要求を送る場面を考えます。排他制御は競合の扱い、冪等性は再実行しても意図しない重複を起こさない性質として学びます。

コードが読み切れないときは、AIの説明を実際の呼び出し先、SQL、テストと照合します。「説明が自然」だけでは確認済みにしません。

正常な受注登録を追った後、DB更新の途中で失敗する場合を考えます。どのデータが残り、利用者には何が表示され、同じ操作を再実行するとどうなるかを説明してください。

読み取りと更新の順序も確認します。同時実行で前提が変わる場合、単に同じ処理を繰り返すだけでは整合しないことがあるため、採用したDBの制御方法と実行結果を確認します。

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