キャッシュは嘘をついている

すべてのキャッシュは約束だ：「このデータはおそらくまだ正しい」。

「おそらく」を十分積み上げると、Netflix Tudumの問題になる — 編集者が記事を保存し、数分待ち、プレビューはまだ古いバージョンを表示。

6ステップの遅延

Netflixの編集プラットフォーム。CQRSアーキテクチャ。Kafkaが書き込みと読み込みパスを橋渡し。Cassandraが読み込みストア。ニアキャッシュがその前に。

ニアキャッシュはスケジュールでリフレッシュしていた、オンデマンドではなく。50フラグメントのページ、それぞれ独自のタイマー。一部は更新される。一部はされない。

半分新しく、半分古いコンテンツ。間違いでもない。正しくもない。ただ嘘。

古いデータ問題

裏で何が起きていたか：

これを50ページフラグメントで掛け算、それぞれ異なるリフレッシュ間隔：

修正：引き剥がす

よりスマートなキャッシュを追加しなかった。TTLをチューニングしなかった。キャッシュを完全に削除した。

ビフォー: CMS → ウェブフック → パイプライン → Kafka → Cassandra → キャッシュ → クライアント。データが古くなれる場所が5つ。

アフター: CMS → RAW Hollow (インメモリ) → クライアント。単一の真実の源。無効化不要。古さ不可能。

RAW Hollow：すべてのサービスインスタンスに埋め込まれたインメモリオブジェクトストア。3年分のコンテンツがインスタンスあたり約130MBに圧縮。すべてのルックアップがO(1)、インプロセス。

ネットワークホップなし。キャッシュ無効化なし。古いデータなし。ただのメモリ読み取り。

数字

ビフォー vs アフター: ホームページ構築が1.4秒から0.4秒に。キャッシュ古さが0-120秒から0秒に。関与コンポーネントが6+から1に。デバッグ複雑度が高から低に。インスタンスあたりメモリが約50MBから約130MBに増加。

トレードオフ: 80MB多いRAM = ゼロの古さバグ。

これが君に当てはまるとき

自問しろ：

• データセットはメモリに収まる？ Netflix Tudum：約130MB。ほとんどの編集コンテンツは小さい。
• キャッシュ無効化がバグを起こしている？ Yesなら、たぶんキャッシュがバグだ。
• キャッシュを積み重ねている？ CDN → Redis → アプリキャッシュ → DBキャッシュ。各レイヤーが独立して嘘をつく。
• 「結果整合性」がユーザーを混乱させている？ ユーザーは保存したものを見ることを期待する。
• キャッシュ問題のデバッグがキャッシングが節約する以上の時間を取っている？

解決策は必ずしも「すべてのキャッシュを削除」ではない。でもキャッシングアーキテクチャがビジネスロジックより多くのコンポーネントを持っているなら、何かがおかしい。

キャッシュ複雑度スペクトラム

シンプル（たいてい大丈夫）: App → Redis → DB。1キャッシュレイヤー、明確な無効化。

危険（慎重に監査）: CDN → エッジキャッシュ → アプリキャッシュ → Redis → DBキャッシュ。5レイヤー、古いデータを配信する機会が5回。無効化が分散システム問題になる。

Netflix Tudumソリューション: App → インメモリデータ。ゼロキャッシュレイヤー。ゼロ古さ。

教訓

最速のキャッシュはキャッシュなしだ。 データセットがメモリに収まるなら、儀式をスキップしろ。

すべてのキャッシュはトレードオフだ：速度 vs 正確性。どちらを選んでいるか知れ。「速度」を選んでいるのに「バグ」を得ているなら、間違った選択をしている。

---

最高のキャッシュ戦略は、キャッシュが全く必要なくなる戦略だ。

— blanho