System Design
決済 API で冪等性キーを持たないと何が起こる？
状況 クライアントからの決済リクエストは、タイムアウト時に自動リトライされます。サーバー側では同じ注文かどうかを本文だけでは厳密に識別していません。 問い この API で冪等性キーを持たないと、どのような失敗が起きやすいでしょうか。特に「...
次の問題へSystem Design
TTLだけに任せたキャッシュ失効はなぜ危ない？
まず考えてから解説へ進みます。答えを覚えるより、判断の理由を言えることを重視します。
Question
まず考える
状況
商品詳細 API のレスポンスを Redis にキャッシュしています。更新時の個別無効化はまだ入っておらず、現在は `TTL=10分` のみで運用しています。
前提
- 商品価格は運営画面から手動で変更される
- 商品説明は頻繁ではないが変更される
- 商品詳細ページは流入が多く、DB への負荷を抑えたい
問い
この設計はなぜ危ないでしょうか。特に、どの条件で実害が出やすいかを説明してください。
Notes
- 一番大きい論点を一文で言えるか
- どの条件で問題化するかを分けて考えられるか
- 代替案を出したとき、その引き換えも言えるか
Explanation
解説
最終更新: 2026-04-20
何が問題か
TTL だけに頼ると、更新後しばらく古い値を返すことを許容する設計になります。価格や在庫のように利用者の判断へ直結する情報では、この遅延が単なる表示ズレでは済みません。
どの条件で問題化するか
- 更新頻度より TTL が長いと、古いデータの露出時間が伸びる
- 更新の影響範囲が広いと、誤表示が大量のユーザーへ届く
- 更新直後にアクセスが集中すると、間違った内容がキャッシュ経由で増幅される
代替案
- 更新時に対象キーを明示的に無効化する
- 価格や在庫のような重要項目だけ短 TTL または別キャッシュ戦略にする
- キャッシュ値へ更新時刻やバージョンを持たせる
トレードオフ
無効化ロジックを入れると実装は複雑になります。とはいえ、重要データの誤表示コストが高いなら、単純さより整合性を優先する理由が立ちます。
補足論点
TTL は悪ではありません。更新頻度が低く、多少の古さが実害にならない情報なら十分妥当です。問題は、TTL を使うことではなく、整合性要件を確認せず一律に採用することです。
Self Check
この問題の理解度を記録
この記録はこのブラウザに保存されます。あとで見返す問題の整理に使えます。