初級ではキャッシュを「付箋メモ」と捉えました。中級では、置き方（戦略）と、いちばんの難所＝無効化を見ます。
中級の解説は準備中のため、中級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
多くはインメモリ（Redis・Memcached など）で、メモリ上に持つので非常に速い。設計は「何を・いつ載せ・いつ捨てるか」が肝です。
- TTL — 一定時間で自動的に捨てる
- 無効化（invalidation） — 元データが変わったら、古いキャッシュを消す／更新する
- キー設計 — 何を鍵にするか（細かすぎるとhitしない、粗すぎると混ざる）
登場人物メモ:
- ※1 cache-aside — アプリがキャッシュを見て、missならDB→書き戻す王道
- ※2 stale-while-revalidate — 古い値を返しつつ、裏で新しい値に更新する
アニメーション『キャッシュ ヒット/ミスの分岐』を開く
仕事の流れ
アニメーション『キャッシュの読み込み（cache-aside）』を開く
- アプリ — データが欲しい側。まずキャッシュを見にいく
- キャッシュ — Redis 等の高速な一時置き場。あれば即返せる
- DB — 本物のデータ源。確実だが読み込みは遅い
0 / 6
- アプリがキャッシュを確認（hit なら即返す）
- miss なら DB から取得
- 取得値をキャッシュに書き（TTL付き）、返す
- 元データを更新した時に、該当キャッシュを無効化 or 上書きする
難所は「無効化」
「キャッシュの無効化はコンピュータサイエンスの難問の一つ」と言われます。
- 整合性 vs 速さ — 古い値（stale）を許すほど速いが、正しさは落ちる
- 書き込み方式 — write-through（同時に書く）／write-back（後で書く）など
- スタンピード対策 — TTLをばらす、再計算をロックで1本化、stale-while-revalidate
- 分散キャッシュ — 複数ノードで共有（Redisクラスタ等）。ノード配置と一貫性が課題
⚠️ うまくいかないとき
- stale（古い値） — 無効化漏れで、更新が反映されない
- キャッシュスタンピード — 一斉missでDBへ集中
- メモリ溢れ — 容量超過で古いものが押し出される（eviction）。何が消えるかを理解して設計する
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 人気データのキャッシュが一斉に期限切れし、DBへ問い合わせが殺到する現象は？
問2. 「キャッシュに無ければDBから読み、その値をキャッシュに書いてから返す」王道の戦略はどれ？
問3. よく使われるインメモリキャッシュ（メモリ上に値を持つ高速なキャッシュ）の代表例はどれ？
問4. キャッシュのキーを「細かすぎる」設計にするとどうなる？
問5. キャッシュのTTLの役割として正しいのは？
問6. 「古い値（stale）を許すほど速いが正しさは落ちる」というトレードオフの主因は？
問7. 元データが変わったとき、古いキャッシュを消したり更新したりする操作を「キャッシュの◯◯」という。◯◯にあたる語を英単語で答えてください。
問8. 古い値を返しつつ裏側で新しい値へ更新する手法を、英字（ハイフン区切りの語）で答えてください。