初級ではキャッシュを「付箋メモ」と捉えました。中級では、置き方（戦略）と、いちばんの難所＝無効化を見ます。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
多くはインメモリ（Redis・Memcached など）で、メモリ上に持つので非常に速い。設計は「何を・いつ載せ・いつ捨てるか」が肝です。
- TTL — 一定時間で自動的に捨てる
- 無効化（invalidation） — 元データが変わったら、古いキャッシュを消す／更新する
- キー設計 — 何を鍵にするか（細かすぎるとhitしない、粗すぎると混ざる）
登場人物メモ:
- ※1 cache-aside — アプリがキャッシュを見て、missならDB→書き戻す王道
- ※2 stale-while-revalidate — 古い値を返しつつ、裏で新しい値に更新する
アニメーション『キャッシュ ヒット/ミスの分岐』を開く
この部分をもっと深く（上級）
キャッシュとDBの食い違いを、どう抑えるか。
- write-through — 書き込み時にキャッシュとDBを同時更新（一貫だが書きが重い）
- write-back — 先にキャッシュ、あとでDB（速いが喪失リスク）
- write-around＋cache-aside — 書きはDBへ、読みでキャッシュに載せる（王道）
- 順序 — 更新は「DB更新→キャッシュ削除」が基本。削除でなく更新にすると競合で古い値が残りやすい
やさしく言うと（初級）
よく引く単語を付箋に書いておけば、毎回辞書（※1 DB）を引かずに済みます。キャッシュはこの付箋。よく使う答えを手元に置き、DBまで行かずに速く返す係です。
ポイントは、キャッシュの中身は消えてもよいこと。無ければDBに取りに行けばいいので、あくまで「近道」です。
登場人物メモ:
- ※1 DB — 大元の正しいデータの置き場（辞書）
- ※2 hit／miss — 手元にある（hit）／無くてDBへ（miss）
仕事の流れ
アニメーション『キャッシュの読み込み（cache-aside）』を開く
- アプリ — データが欲しい側。まずキャッシュを見にいく
- キャッシュ — Redis 等の高速な一時置き場。あれば即返せる
- DB — 本物のデータ源。確実だが読み込みは遅い
0 / 6
- アプリがキャッシュを確認（hit なら即返す）
- miss なら DB から取得
- 取得値をキャッシュに書き（TTL付き）、返す
- 元データを更新した時に、該当キャッシュを無効化 or 上書きする
この部分をもっと深く（上級）
- TTL＋ジッタ — 期限を散らし、一斉失効を避ける
- single-flight — 同一キーの再計算を1本に集約
- stale-while-revalidate — 古い値を返しつつ裏で更新
- negative caching — 「無い」という結果も短くキャッシュ（無駄な問い合わせ抑制）
やさしく言うと（初級）
- バックエンドが「この答えある？」とキャッシュに聞く
- あれば即返す（hit・速い）
- 無ければDBに取りに行き（miss）、その答えをキャッシュに置いてから返す
- 次からは、同じ問い合わせはキャッシュから即返せる
難所は「無効化」
「キャッシュの無効化はコンピュータサイエンスの難問の一つ」と言われます。
- 整合性 vs 速さ — 古い値（stale）を許すほど速いが、正しさは落ちる
- 書き込み方式 — write-through（同時に書く）／write-back（後で書く）など
- スタンピード対策 — TTLをばらす、再計算をロックで1本化、stale-while-revalidate
- 分散キャッシュ — 複数ノードで共有（Redisクラスタ等）。ノード配置と一貫性が課題
この部分をもっと深く（上級）
- eviction — LRU／LFU／W-TinyLFU／ARC。ヒット率と実装コストのバランス
- コンシステントハッシュ — ノード増減で動く鍵を最小化。仮想ノードで平準化
- near cache — アプリ内の1次キャッシュ＋共有の2次キャッシュ（多層）
- ホットキー — 1つの鍵に集中。複製やローカル化で分散
やさしく言うと（初級）
名前が似ていますが役割が違います。
- CDN — “配信”の近道。画像など変わらないものを、利用者の近くから配る
- キャッシュ — “処理”の近道。よく使う答えを手元に置き、DB往復を減らす
どちらも「速くするための、消えてよい控え」という点は共通です。
⚠️ うまくいかないとき
- stale（古い値） — 無効化漏れで、更新が反映されない
- キャッシュスタンピード — 一斉missでDBへ集中
- メモリ溢れ — 容量超過で古いものが押し出される（eviction）。何が消えるかを理解して設計する
この部分をもっと深く（上級）
- スタンピード — 一斉ミスでDB殺到（上の対策で緩和）
- 整合性の破れ — 更新とキャッシュ削除の競合で古い値が固定される
- キャッシュ汚染 — 個人向け応答を共有キャッシュへ載せる事故
- メモリ圧迫 — evictionで必要なものまで押し出される（サイズ設計）
やさしく言うと（初級）
- 古い値が残る — 元データが変わったのに、古いメモを返してしまう（無効化が要る）
- キャッシュが飛ぶとDB殺到 — 一斉にmissが起きて、DBに問い合わせが集中する
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 人気データのキャッシュが一斉に期限切れし、DBへ問い合わせが殺到する現象は？
問2. 「キャッシュに無ければDBから読み、その値をキャッシュに書いてから返す」王道の戦略はどれ？
問3. よく使われるインメモリキャッシュ（メモリ上に値を持つ高速なキャッシュ）の代表例はどれ？
問4. キャッシュのキーを「細かすぎる」設計にするとどうなる？
問5. キャッシュのTTLの役割として正しいのは？
問6. 「古い値（stale）を許すほど速いが正しさは落ちる」というトレードオフの主因は？
問7. 元データが変わったとき、古いキャッシュを消したり更新したりする操作を「キャッシュの◯◯」という。◯◯にあたる語を英単語で答えてください。
問8. 古い値を返しつつ裏側で新しい値へ更新する手法を、英字（ハイフン区切りの語）で答えてください。