設計考量

錯誤處理：如果快取因任何原因而無法使用，應用程式應繼續執行，就像所有項目都是快取遺漏一樣。快取層的存在不應將脆弱性新增至應用程式。

TTL：可以為所有快取項目設定單一 TTL 值，或根據項目 （例如 get_item、 query或 scan快取） 使用不同的 TTL 值。負快取項目也有不同的 TTL 值 （未傳回項目的請求）。

耗用容量：當您傳回快取的回應時，建議您調整回應中的ConsumedCapacity指標，以表示零讀取耗用。

移除回應中繼資料：您也應該移除回應中的 ResponseMetadata區段。這可避免有人看到 的風險，RequestId並認為它在實際是數小時前時是最新的。

新增快取中繼資料：將CacheMetadata區段新增至回應會很有幫助。本節可以報告儲存值的時間 （用於測量過時），以及儲存值的用戶端程式庫和版本 （在執行從一個版本無縫升級到另一個版本時可能很有用，因為格式變更）。

判斷資料表結構描述：若要從寫入操作判斷主索引鍵以進行快取失效，您必須知道資料表的結構描述。您可以在每個資料表初次使用 （僅限一次） 時，在 ElastiCache 中使用describe_table呼叫和長期快取來取得此資訊。

接受而不是建構用戶端：在建構函數中接受 DynamoDB 和 Redis 用戶端執行個體 （而不是根據傳入參數在 shim 中建置它們） 的優點是它可讓建構函數的發起人決定詳細資訊，例如是否read_from_replicas=True應設定 。

命名空間功能：在建構函數中支援選用的命名空間相當方便，它會隔離所有快取讀取和寫入該命名空間。使用命名空間非常適合用於測試，因為每個使用不同命名空間的執行似乎從空快取開始，並且沒有先前執行的副作用。您也可以透過變更命名空間，模擬在生產環境中清空完整快取。這可以透過自動將字首新增至每個查詢金鑰來實作。

掃描快取：很難知道是否應快取scan呼叫。執行一次性完整資料表掃描時，您不想使用不會再次讀取的大型掃描資料頁面來填充快取。另一方面，許多工作負載會重複掃描，特別是針對較小的資料表，以提供最新的完整資料表資料給多個下游消費者。一種危害是實作系統，其中需要兩個呼叫，而且每個呼叫都有相同的簽章 （在 TTL 期間內），以便快取產生的掃描回應。這可避免在一次性完整資料表掃描期間填入快取，同時讓緊密的掃描迴圈獲得快取的優勢。第一次掃描會在快取中放置一個小型預留位置，以將請求標示為已完成一次。第二次掃描會將字符值取代為實際承載，最大可達 1 MB。