快取：先留一份，下次不用重新查

以使用者的常用收件地址清單為例，內容可能很久才改一次，卻會在選擇收件資訊時反覆讀取。如果每次都查資料庫，拿到的又是相同內容，就可以考慮把查詢結果先保存一份，供後續使用。這就是快取：重複利用已取得的資料或計算結果，減少重新取得的成本。

不過，少改不代表一定值得快取。如果清單很少被讀取，原本查詢也很快，增加快取未必有明顯效益。需要一起考慮的，是讀取頻率與實際查詢成本。

而且原始資料改了，快取也需要有更新方式。使用者修改常用地址後，資料庫已保存成功，畫面卻可能仍讀到快取中的舊地址。這時「儲存成功」與「看到舊資料」可以同時發生。

這裡談的是下次填寫時使用的常用地址清單，與已成立單據保存的收件資訊不同；修改常用地址，不代表連帶修改既有單據。

省下查詢，也多了一份要管理的資料

常見的讀取方式是先查快取，有資料就使用；沒有時才查原始來源，再把結果放入快取。好處是減少重複查詢或計算，縮短回應時間，也降低原始來源的負擔。

代價則是額外的儲存空間、更新流程，以及可能讀到舊資料。保存期限越長，資料有更多機會被重複使用，但如果只等過期才重新取得，修改也可能更久才出現在畫面上。

依保存位置，可以先認識三種常見方式：

• 用戶端快取：資料留在瀏覽器或App，例如畫面保存已載入的地址清單，減少再次呼叫API。要處理重新整理資料與切換帳號時的清除。
• 應用程式內的記憶體快取：資料放在處理請求的程式裡，讀取方便，但通常只供該程序使用，其他程序不會自動取得它的更新。
• 共用快取服務：多台Server透過網路存取同一套快取，例如使用Redis。可以減少各自保存造成的差異，但多了網路存取與服務維運成本。

這些方式可以並存，但每多留一份，就多一個需要確認更新時機的地方。個人的地址清單，當然也要確認快取依使用者區分，避免讀到別人的資料。

一台Server夠用，兩台之後呢？

假設一開始只有一台Server，而且只有一個應用程式程序，可以先用程序內的記憶體快取保存地址清單。修改成功後清除對應使用者的快取，下次查詢就重新取得資料。用戶端若也留有清單，同樣需要刷新。

為了分擔流量或維持可用性，系統可能部署兩台以上的Server。如果A、B各自保存一份記憶體快取，使用者修改地址的請求送到A，A更新資料庫並清除自己的快取，B卻可能還留著舊資料。

接著查詢由A處理，看到的是新地址；下次由B處理，又出現舊地址。若保存期限很長，這種落差也可能持續很久。單機測試正常，並不足以證明多台部署後仍符合預期。

一種做法是讓各台共用快取，修改後清除共用的那筆資料；另一種是保留各自的快取，但發出失效通知，讓其他程序也清除舊值。後者還要考慮通知漏收時如何補救，例如以到期重取作為後備。

共用快取也不代表所有更新問題都消失。如果某次查詢在修改前讀到舊資料，卻在快取清除後才把舊值放回去，仍可能再次出現舊內容。因此還要核對讀取、寫入與清除交錯時的結果，不能只確認「有清快取」。

選擇快取方式，要回到需求

AI在設計功能或改善效能時，可能主動加入快取。我們需要讓AI了解實際部署方式與使用情境，才能真正地確認「查詢成本是否值得增加快取？資料可以舊多久？修改後哪些地方需要更新？更新失敗時，功能會怎麼表現？」

如果需求是修改地址後立即選用新內容，就不能只靠一個很長的到期時間。如果流量與查詢成本都不高，也不必為了這份清單引入共用快取服務與通知機制。

需求若容許短暫延遲，可以採用最終一致的方式：在沒有後續修改、更新機制正常運作後，各份資料逐漸收斂。但還是要訂出可接受的延遲，不能只用「最後會更新」來忽視使用者體驗。

快取加快了回應，但不能改變功能原本該遵守的規則

「客戶說地址改了三次，畫面還是舊的。這是Bug吧？」
「你看到的是Bug，我看到的是百分之百的快取命中率。」