Headless storefront 可以在瀏覽器、server、framework data layer、CDN、Shopify 與 CMS 多層快取。若沒有共同策略，同一商品可能在列表顯示新價格、商品頁仍是舊價格；團隊也可能為了怕舊資料，把所有 query 設成 no-cache，失去效能與穩定性。
設計快取從資料新鮮度和顧客風險開始，不從一個全站 TTL 開始。
先做資料分類
將資料分為長效品牌內容、一般商品內容、高變動價格與 availability、搜尋結果、cart/customer 私有狀態，以及 preview draft。每類記錄 source、更新事件、可接受陳舊時間、是否因 market 或身分變化，以及錯誤時可否使用 stale data。
價格和可售資訊若過期會影響交易，策略應比文章內容保守。Cart 與 customer data 不可進共享 public cache。
Cache key 必須包含情境
URL 只是 key 的一部分。Locale、country、currency、market、query variables、customer state 和 preview mode 都可能改變結果。缺少 country 可能把台灣價格送到其他市場；缺少 preview flag 可能讓草稿污染公開頁面。
避免把所有 cookie 都放進 key，會讓 cache 完全碎片化。只選真正影響 response 的情境，並在程式中集中定義。
TTL、stale 與背景更新
長效內容可用較長 TTL 配合 publish webhook；商品頁可使用 stale-while-revalidate，先回傳可接受舊內容，再於背景更新。高風險交易資料在加入購物車和 checkout 前重新向 Shopify 確認，不能只相信頁面 cache。
API 暫時失敗時，品牌文章可回 stale，價格與庫存則要依風險顯示暫時不可確認或採安全流程。每類資料都要寫出 failure policy。
Webhook 失效要精準且可重送
Shopify product update、publication、inventory 事件與 CMS publish 可觸發 revalidation。建立 product/document 到 URL 或 cache tag 的映射，只失效相關商品、集合與內容頁。事件 handler 保持 idempotent，記錄 event ID、時間、範圍和結果。
Webhook 可能遺漏，因此安排 reconciliation 或短 TTL 作為安全網。一次活動更新數千商品時，批次合併失效，避免造成 origin stampede。
Preview 完全隔離
Draft query 使用授權 token、preview perspective 和 private no-store 或隔離 cache。Preview response 不得被 CDN public cache，也不能產生可索引 canonical。結束 session 後，production request 應回到 published data。
測試兩個使用者同時預覽不同草稿，確認不會互相看到內容。只測一位編輯者容易漏掉 cache key 問題。
防止 cache stampede
熱門商品過期時，大量 request 可能同時回 origin。使用 request coalescing、lock、stale response、jittered TTL 或背景 refresh，讓只有少數請求更新。設定 API timeout 和 fallback，避免一個慢來源佔滿 server resources。
大促前以預期流量測 cold cache、warm cache 和失效後重建。命中率高不代表安全，還要看 tail latency 和 origin error。
讓快取可觀測
Response header 或 trace 記錄 HIT、MISS、STALE、BYPASS、age、key version 和資料來源。Dashboard 追蹤 hit rate、revalidation、origin latency、失敗與不同 market。客服回報舊資料時，工程師才能判斷是哪一層。
每次模型或 query 變更提升 cache key version，避免新程式讀到舊 shape。把分類表、key、TTL、webhook、fallback 和 owner 放進 Headless Shopify 架構，並用真實商品更新演練驗證。