正解: D

Write-Behind（Write-Back）は書き込みをキャッシュに即時反映し、DBへの永続化を非同期バッチで行う。書き込みスループットが高い代わりに、クラッシュ時のデータロス可能性がある。最終的な整合性で十分なユースケース（IoTデータ集約、ログ記録等）に適している。

正解: D

volatile-lfu は TTL が設定された（volatile な）キーの中から、LFU（Least Frequently Used = アクセス頻度が低い順）で削除する。永続データとキャッシュデータが共存する Redis インスタンスで、キャッシュデータのみを Eviction 対象にしたい場合に有効。

正解: B

max-age=0 によりブラウザキャッシュは無効（毎回再検証）。s-maxage=300 によりCDN（共有キャッシュ）は300秒キャッシュ。stale-while-revalidate=600 により、CDNキャッシュ失効後も600秒間はstaleデータを返しつつバックグラウンドでオリジンに再取得する。

正解: B

Cache Stampede は、人気のあるキャッシュキーの TTL が失効した瞬間に、多数のリクエストが同時にキャッシュミスとなり、一斉にオリジン（DB等）にアクセスして過負荷を引き起こす問題。防止策としてロック、PER（確率的早期再計算）、stale+バックグラウンド更新がある。

正解: C

Redis Cluster は 16,384 個のハッシュスロットを持ち、各ノードがスロットの一部を担当する。キーの配置は CRC16(key) mod 16384 で決定される。ハッシュタグ {...} を使うことで、関連キーを同一スロットに配置できる。

正解: B

オリジンシールドはエッジロケーションとオリジンサーバーの間に位置するリージョナルキャッシュ。複数のエッジロケーションからのリクエストを集約することで、オリジンへのリクエスト数を大幅に削減する。キャッシュミス時も、オリジンシールドにヒットすれば高速に応答できる。

正解: B

インプロセスキャッシュは各アプリケーションインスタンスのメモリ内に独立して存在する。そのため、あるインスタンスでデータが更新されても、他のインスタンスのキャッシュには反映されず、一時的なデータ不整合が発生する。Redis Pub/Sub 等で無効化を通知する仕組みが必要。

正解: C

全てのキャッシュエントリが同じ TTL で同時に失効すると、一斉にオリジンへのリクエストが発生する（Cache Stampede の一因）。TTL にランダムな揺らぎを加えることで、失効タイミングを分散させ、オリジンへの負荷を平準化できる。例: 300秒 ± 10% → 270〜330秒。