Key Space

Key space 的責任是定義快取資料如何被定位、分組、失效與遷移。key 命名要包含資料責任、版本、租戶或區域等必要維度，讓失效與回退可控。

常見 key 維度包含：

1. 資料類型，例如 product、user-permission、quota。
2. 版本，例如 v1、v2。
3. 租戶或區域，例如 tenant、region、locale。
4. 實體識別，例如 product id、user id。

key 缺少版本時，cache migration 會變成破壞性替換。key 缺少租戶或區域時，失效範圍會被放大。

Value Shape

Value shape 的責任是定義快取值的語意與演進方式。完整 JSON blob 適合一次讀取完整資料，但欄位更新與版本相容成本高；hash 適合欄位局部更新，但需要明確欄位責任；set 與 sorted set 適合集合與排名；counter 適合限流或計數。

資料形狀的本質是服務責任選擇，Redis 語法是落地方式。

string / blob 的判讀重點是整包資料是否需要一起讀取與一起失效。hash 的判讀重點是欄位是否真的能獨立更新。set 與 sorted set 的判讀重點是 membership 或排序錯誤會造成什麼後果。counter 的判讀重點是原子性與過期窗口。stream 的判讀重點是這條路徑是否已經接近 message queue 責任。

Access Pattern

Access pattern 的責任是定義快取面對的讀寫節奏。高讀低寫、熱點讀取、短期活動尖峰、租戶隔離與跨區讀取，都會影響 key 設計與容量策略。

高讀低寫適合長 TTL 與背景刷新；熱點讀取需要 hot key 保護；短期尖峰需要 warmup 與分散過期；多租戶場景需要避免單租戶 key 壓垮共享 cache。

Multi-layer Cache

多層快取的責任是分散延遲與來源壓力。常見層次包含 process local cache、distributed cache、CDN 或 search/read model。每一層都需要定義 freshness、失效來源與 fallback。

多層 cache 的主要風險是 stale 疊加。local cache stale、distributed cache stale 與 CDN stale 缺少共同失效策略時，讀者看到的錯誤會很難追。

ML feature store 的多層 cache 設計模式

ML inference 場景的 feature lookup 是多層 cache 的典型應用。9.C25 Tubi feature store 的策略段提出 可重用做法：用 L1 in-process cache + L2 distributed cache + L3 持久 store 三層。Tubi 實做的是把 feature store 從 ScyllaDB 遷到 ElastiCache（屬於 L2 層的選擇）、p99 < 10ms；三層架構是策略段推導出的通用設計、不一定 Tubi 完整實做。

通用三層模式（推導自 9.C25 策略段、實際分層深度視 workload）：

• L1：in-process cache：跟 application 同一 process、避免 network hop、適合最熱的少量 features
• L2：distributed cache（ElastiCache / Memcached）：跨 application instance 共享、能擴容、Tubi 在這層用 ElastiCache 達 p99 < 10ms
• L3：持久 store（ScyllaDB / DynamoDB / S3 + Parquet）：全量資料、cache miss 時的 fallback

判讀重點：每層的 latency budget 跟 stale window 都應依 workload 跟業務容忍度設定。相對序列是 L1 stale window 最嚴、L2 中等、L3 為 source-of-truth 或可重算來源。三層 stale 若無共同失效策略、業務代價會落到 推薦結果不穩定、用戶看到不同 session 推不同內容。

跨 cloud 部署的資料引力（路由：見 2.7）

跨 cloud cache 部署的 資料引力 原則跟 跨區一致性 議題密切相關、主寫場域是 2.7 cache copy boundary 的跨區一致性窗口。本章從 data shape / access pattern 角度補充：當 cache value 包含跨 region 共享的業務資料時、access pattern 自然偏向 同 cloud read + 跨 cloud batch sync、不適合即時跨 cloud lookup。詳見 9.C35 Snap KeyDB 案例。

選型前判準

快取資料形狀選型前要先回答：

1. 讀取是單 key、批次 key、集合、排序還是計數。
2. 寫入是整體替換、局部更新、追加還是原子遞增。
3. 失效是單 key、群組、版本、租戶還是全域。
4. 資料結構是否會讓快取承擔正式狀態責任。

這些問題決定後續要比較 Redis data type、Memcached blob、CDN cache 或應用端 local cache。

實體服務討論承接點

實體快取服務文章要承接本篇的 data shape 與 access pattern。Redis/Valkey 的 hash、set、sorted set、stream 能表達多種資料形狀；Memcached 偏向簡單 key/value blob；CDN 與 local cache 則承擔不同層次的讀取加速。比較服務時要先問 access pattern，再問語法。

若讀取是單 key 或 blob，後續文章要比較 serialization、value size、TTL 與 eviction。若讀取是集合、排名或計數，後續文章要比較資料結構、原子性與容量行為。若讀取跨多層 cache，後續文章要比較失效傳播、stale 疊加與 observability。

下一步路由

要處理 TTL 與容量策略，接著讀 2.3 TTL 與 eviction。要看選定形狀後各型別的操作語意、原子性與記憶體曲線，接著讀 2.11 Redis data types 實作。要處理 presence 類即時狀態，接著讀 2.5 presence store 與即時狀態。