生成に費用がかかり、頻繁に読み取られ、めったに変わらないデータをキャッシュします。これが最もキャッシングの効果を発揮します。TTL（time to live）は、鮮度（データがどれほど最新である必要があるか）と陳腐化許容度（どれほど間違っていても、どのくらいの期間なら許容できるか）のトレードオフです。
キャッシュするもの
良いキャッシュ候補は、以下の3つすべてでスコアが高くなります。
生成に費用がかかり、頻繁に読み取られ、めったに変わらないデータをキャッシュします。これが最もキャッシングの効果を発揮します。TTL（time to live）は、鮮度（データがどれほど最新である必要があるか）と陳腐化許容度（どれほど間違っていても、どのくらいの期間なら許容できるか）のトレードオフです。
良いキャッシュ候補は、以下の3つすべてでスコアが高くなります。
計算が安い、書き込みが多い、またはユーザーごとの秘密データで、鮮度が正確である必要があるもの（例えば、トランザクション時点でのアカウント残高）はキャッシュしないでください。
Staleness tolerance → TTL:
config / static reference data → long (hours to days)
product listings, article body → medium (minutes)
prices, stock, leaderboards → short (seconds)
must always be exact → don't cache, or use explicit invalidation
予測不可能な変更があるデータの正確性のために、TTLと明示的な無効化を組み合わせます。write-throughまたはdelete-on-writeにより、有効期限を待つのではなく、ソースが変更された瞬間にキャッシュを破棄します。
on update(record):
db.save(record)
cache.delete(key(record)) // invalidate now, don't serve stale until TTL
hit ratio = hits / (hits + misses)
high (>90%) → cache is doing its job
low → TTL too short, keys too granular, or data not cacheable
キャッシュヒット率を監視してTTLをチューニングします。低いヒット率はほとんどキャッシュしていないことを意味し、陳腐化に関するコメントが多い高いヒット率はTTLが長すぎることを意味します。
何をキャッシュするか、TTLを正しく設定することは、効果的なキャッシングの核心です。間違ったものをキャッシュすると、複雑さが増すだけで利益がありません。TTLが長すぎると古いデータを配信し、短すぎるとメリットが失われます。陳腐化許容度を使用してTTLを選択し、正確性のための明示的な無効化を追加し、ヒット率を監視することで、原則的で測定可能なキャッシング方法を手に入れることができます。