Product variations can make a shop repeat expensive work: loading options, calculating displayed prices and preparing images and controls. I cache that response only after listing every input which can change the answer. The first check is whether two requests are entitled to receive the same price and product information.
I distinguish a reusable public product response from the customer-specific state used to complete a purchase. That gives the cache a clear boundary before any warming or expiry policy is added.
A product ID does not describe a price
The cache key needs to reflect the inputs which change the output. For a public variation response, that can include the product and variation, their modification state, price data, currency and the shop’s tax-display settings. A batch response also needs the set of variation IDs the browser requested.
I normalise that set before building the key. Otherwise two requests for the same public options in a different order could create separate entries and miss an easy opportunity to reuse the work. If presentation order matters to the response, I preserve or reconstruct it deliberately rather than silently changing what the caller asked for.
State the boundary of the shared result
I limit a shared guest-data cache to information which is appropriate for any visitor receiving it. A shopper’s basket, address and account need their own handling. Those details belong to the current customer and cannot be folded into a public response because the surrounding product page happens to be public.
A shop with customer-specific prices, tax based on an address, membership discounts or several currencies needs a more detailed policy. Either the output varies on every relevant input, or that request does not use the shared entry. I would rather leave a complicated pricing path uncached than make a quick answer out of the wrong price.
Warm what the browser actually requests
I schedule a background refresh after product edits using the same chunks of visible variations that the front end requests. Warming an entire product under a different key would not help the first real batch request.
I deduplicate the job so an edit burst does not create a queue of identical work. Background warming reduces the likelihood of a cold request; it does not remove the need for a working miss path if the job is delayed or the entry has expired.
Test freshness and the final purchase
I compare a cold response and a warm one, then change a variation price and request it again. I also check the supported currency and tax contexts, unpublished options and a basket with existing items. A cache lifetime is a fallback, not a substitute for recognising a meaningful change.
The server must still validate the current purchasable item and calculate the order correctly when it is added. Cached display data is not an authority to charge an old price.
On the interface side, I have also written about giving product options useful loading and error states. Faster data and clear feedback work best together.