プロダクト向けAPIのキャッシュ戦略

鮮度契約に名を付ける

Redis、CDN規則、HTTPヘッダーを選ぶ前に、応答がどれだけ古くてよいか、間違ったときに何が起きるかを決めろ。プロフィールページ、在庫数、価格、権限は遅延耐性が異なる。単一のグローバルTTLは通常プロダクトミスだ。

クライアントが頼れるエンジニアリング言語で契約を書け：絶対期限、イベント駆動無効化、または明示的再検証。曖昧な鮮度は、互いに争う重複キャッシュ層を生む。

観客のいるところにキャッシュする

公開コンテンツはエッジキャッシュの恩恵を受ける。ユーザーごとのダッシュボードは、しばしば身元とテナントでキー付けしたアプリレベルキャッシュが要る。高価な集計は、短命なキーバリューではなくマテリアライズが必要な場合がある。

未認可応答や秘密を埋め込む応答をキャッシュするな。キャッシュキーは意味を変える全次元——ロケール、プラン、機能フラグ、表現バージョン——を含めなければならない。

• 期限切れ時のサンダリングハードから守る
• 冪等な再計算経路を好む
• ヒット率と誤データインシデントを一緒に観測する
• 意味のあるドメインイベントで無効化する

無効化が難しい部分だ

時間ベースの期限は単純で、協調データにはしばしば間違っている。イベントベース無効化は精密で、プロデューサーの抜けを起こしやすい。多くのシステムは、重要エンティティに適度なTTLと書き込み経路での明示パージを組み合わせる。

削除と更新フローがキャッシュに必要な信号を出すよう設計しろ。書き手が読み手のキャッシュを知らなければ、古いデータは繰り返しのインシデントテーマになる。

ユーザーに見える成果を測る

ヒット率が高くても、古い情報へのサポートチケットが増えるなら勝ちではない。レイテンシ百分位、オリジン負荷、正しさの苦情を一緒に追跡しろ。キャッシュ戦略は、プロダクトを速く、かつ信頼できるように感じさせねばならない。

最高のキャッシュは見えない：ユーザーはタイムリーな答えを得、オリジンは落ち着き、エンジニアはデータがいつ遅れてよいかを正確に説明できる。