Off Platform AWS Caching

Digital Commerce has an AWS tier to use as a caching layer for API response caching. It uses the Redis cache for caching the data and runs Lambda instances. It also supports data migration from Salesforce persistent cache to the AWS cache tier.

Versioning allows different versions of the products in different frames of time using two layers of cache.

• The first layer contains a currently active response value cached with a cache key with a time to live (TTL) value of the expiration time of the cached response entry.

• The second layer is a hashmap of the keys that are effective on a future date with the key as cacheKey_future.

• The future cache keys are appended with the timeframes on which they become active.

When there is a request made to the AWS tier, the system checks the Redis cache for an entry with that key. If found, the system returns the response. If the key is not found, or has exceeded the TTL, it checks for the key in the second layer (cachekey_future). This key contains the list of cacheKeys with future effectivity. From that, the system gets the currently effective key, caches it against the cacheKey, and returns in the response. If another request is made, the response is fetched from layer1 with the same cache key.

The Cache Migration feature allows the cache on SFDC to migrate to the AWS Redis cache. There are two main use cases for cache migration:

• There is no cache on Redis and fresh cache data migrates from SFDC to AWS.

• There is already cached data on Redis and data needs correcting because of changes in EPC. New cache is generated on SFDC.

With versioning, there could be multiple instances of cache data with the same cache key but different effectivity dates. With two layers of caching, the effective cache in the current time frame overrides the earlier cache data with the same cache key. With the data having future effectivity and the same cache key, the timeframes are appended to the cache key and the record is cached with that cachekey. A hashmap is created (cacheKey_future) and adds the versioned cache key to the list. The versioned cache key overrides any existing cache key with the same future time frame dates.