快取用空間換時間，把熱資料放在離使用者更近、更快的層。難的不是讀，是寫入與失效時的一致性。
🧠 Core Ideas
TIP
先問三件事：誰負責寫 DB？快取何時更新？資料能容忍多舊？ 答案決定用哪種模式。
⚖️ 讀寫模式 (Tradeoffs)
Cache-Aside (Lazy Loading) — 最常見
- 讀：先查 cache，miss 再讀 DB 並回填。
- 寫：寫 DB，然後讓 cache 失效（而非更新）。
- 優點：只快取真正被讀的資料；缺點：首次 miss 有延遲，且寫後到失效間有短暫不一致。
Write-Through / Write-Back
- Write-Through：寫 cache 同時同步寫 DB → 一致但寫入較慢。
- Write-Back：先寫 cache、非同步刷回 DB → 寫入快但有掉資料風險。
失效難題 — TTL vs 主動失效
- TTL 簡單但有「過期前讀到舊資料」窗口。
- 主動失效精準但要追蹤依賴，複雜度高。
- 熱 key 過期瞬間湧入 DB = cache stampede，用提前刷新 / 互斥鎖緩解。
🔑 Takeaways
- 預設用 cache-aside + 寫後失效，最穩。
- 一致性需求高就 write-through；寫吞吐優先才考慮 write-back（接受掉資料風險）。
- 永遠要想 stampede 與熱 key 的退化情況。
範例紀錄
- Q: cache-aside 寫後為何「失效」而不是「更新」？
- A: 更新需要算出新值（可能要再查 DB），且兩個並發寫會 race 出錯序；直接失效讓下次讀重建，較不易出錯。