Cache Management

Most anonymous visitors on a commerce website spend most of their browsing experience viewing products that capture their interest. Consequently, as users make their way down the commerce funnel towards purchasing the product, we organically create the cache based on the request made to our Industries CPQ engine. As time goes by, we have a robust set of cached records within our cached response object.

What is cache management? When Digital Commerce API calls are made, the API response cache is checked before processing the request. The handling of API requests and cache creation is cache management. Cache management covers the Awareness, Interest, Desire, and Decision phases of a customer journey as depicted in the illustration.

Each customer action corresponds to a cache management API. Viewing products is the Get Offers API. Viewing product details is the Get Offer Details API. Configuring a product is the Configure API. Intent to purchase is the Basket Action API. Purchasing is the Create Order API.

This graphic illustrates an example use-case: anonymous browsing at the top of the funnel and new user checkout near the bottom of the funnel. Other industry examples can have differing percentages. For example, a media industry Pay Per View event could indicate more than 90% of visitors viewing your product landing page through complete purchase with 0% traffic intending to purchase, due to the nature of the Pay Per View user experience.

You can also customize and optimize the relevant Cache Management jobs by leveraging Cache Management APIs. But before we look at the Cache Management APIs, let's better understand the concept of cache management.

A cache miss is when an application makes an API request, but the requested response is not in the cache and needs to be processed.

A cache hit is when the request is found and retrieved from the cache response object.

For example, you are making a Digital Commerce API call to retrieve a list of offers for a sales catalog named Tablets. The API response cache is checked to see if there is a match for the request. If there is a match, then it is a cache hit, and it quickly returns the cached tablets offer list. If there is no match, a cache miss occurs and the Industries CPQ engine processes it before returning the appropriate tablets offer list and adding it to the cache to help reduce cache misses.

In terms of the Digital Commerce APIs, specific data not found in the cache could be related to basket configurations, uncached eligibility contexts, or logged-in user contexts. Digital Commerce is designed to reduce cache misses during the Browse, Configure, and Cart phases of the user journey, but cache misses are an inevitable occurrence.

Organic cache creation is the generation of cache responses during a real-time request. Organic cache creation is triggered during a cache miss scenario. Digital Commerce organically creates the cache for all Basket operations and the GetOffers and GetOfferDetails requests for logged-in user contexts.

Inorganic cache creation is the generation of cache responses as executed by the cacheable API jobs. It increases cache hit scenarios and reduces cache misses to improve performance. Digital Commerce allows you to inorganically create the cache for GetOffers and GetOfferDetails for anonymous users by running the Populate Cache API jobs.

For both organic and inorganic cache creation, the number of generated cached permutations is determined by variations in the product catalog and the cached values specified as part of context dimensions.

There are currently two ways to manage your cached responses. The first is by executing the Populate Cache Job. This job concentrates on addressing the top of the commerce funnel journey. Specifically, the top of the funnel is to support anonymous browsing of the commercial product catalog and viewing the product details.

As users make their way down the commerce funnel towards purchasing the product, you organically create the cached based on the request made to the CPQ Engine. As time goes by, you end up with a robust set of cached records within your cached response object.

However, when a product administrator makes changes to an existing product catalog, for example modifying an associated attribute or price, we then update the existing cache that corresponds to the change. This brings us to the second way to manage the cache, which is by executing the Regenerate Cache Job. This job concentrates on making updates to the existing cache based on changes made to the product catalog.

The Cache Management APIs are intended to work with your continuous integration/continuous development implementation.