System Design
TTLだけに任せたキャッシュ失効はなぜ危ない？
状況 商品詳細 API のレスポンスを Redis にキャッシュしています。更新時の個別無効化はまだ入っておらず、現在は `TTL=10分` のみで運用しています。 前提 商品価格は運営画面から手動で変更される 商品説明は頻繁ではないが変更...
次の問題へSystem Design
決済 API で冪等性キーを持たないと何が起こる？
まず考えてから解説へ進みます。答えを覚えるより、判断の理由を言えることを重視します。
Question
まず考える
状況
クライアントからの決済リクエストは、タイムアウト時に自動リトライされます。サーバー側では同じ注文かどうかを本文だけでは厳密に識別していません。
問い
この API で冪等性キーを持たないと、どのような失敗が起きやすいでしょうか。特に「ネットワークが不安定な時」に何が危険かを説明してください。
Notes
- 一番大きい論点を一文で言えるか
- どの条件で問題化するかを分けて考えられるか
- 代替案を出したとき、その引き換えも言えるか
Explanation
解説
最終更新: 2026-04-20
何が危険か
タイムアウト後の再送時に、最初の決済が成功していたかどうかを呼び出し側が判断できないと、同じ意図のリクエストが複数回処理される可能性があります。決済ではこれは二重課金に直結します。
なぜネットワーク不安定時に危険か
レスポンスが届かなかっただけで、サーバー側の処理自体は完了していることがあるからです。クライアントから見ると失敗でも、サーバーから見ると成功というズレが生まれます。
代替案
- クライアントに冪等性キーを送らせる
- サーバー側でキーと処理結果を一定期間保存する
- 同一キーへの再送では新規実行せず、過去結果を返す
トレードオフ
保存期間やキー衝突管理など運用上の設計は増えます。それでも、金銭的な事故コストに比べれば十分に払う価値のある複雑さです。
補足論点
これは決済だけの話ではなく、メール送信、在庫確保、外部連携の webhook でも同じ構図が起きます。副作用のある API ほど、再送時の扱いを明示する必要があります。
Self Check
この問題の理解度を記録
この記録はこのブラウザに保存されます。あとで見返す問題の整理に使えます。