当一个元素受特定用户情况影响时，我如何从缓存中受益

Question

We have a page that lists products for an e-commerce platform, which updates every 30 minutes and we cache it for 30 minutes as it gets a lot of views.

However there is a "buy" button on it, and if a user has already bought it needs to change from "buy" to "bought" and therefore suddenly makes the caching complex.

What is the right approach to this, where we benefit from cache but also make sure the buy/bought button per product per user is accurate?

Anyone have experience?

Answer 1

If I understand your posting correctly, what you want to do is to cache as much of the page's data as possible without caching specifically the "user has purchased this item or not" part.

In short:

The solution here is to separate the cacheable data from the not-cacheable data. Then, on page load, do the following:

1. Read the cacheable data from cache
2. Read the non-cacheable data from wherever it is stored.
3. Combine them together into the web page to display to the end user

I think this is a very common way of optimizing performance for high traffic web pages or mobile app screens (at least we do it quite a bit at my company). The benefit here is that you are improving page load times by caching as much as possible - while still making sure the business logic functions as required (in your case, making the "buy/bought" button work properly).

Now, about how you could actually do this in practice:

The first step is for you to understand your data and how it needs to be cached. Some data may not be cacheable at all, and some may have specific caching requirements (for example, your logic may require that the cache for certain data will be invalidated for different reasons than other data) which means it must be cached separately from other data. It sounds like you have already done this. As you've described, your data falls into the following two categories:

• Not-cachable: User item purchase status for each item on the page
• Cacheable (30 minutes): everything else on the page

Now that you understand your data, what you need to do is set up your application to cache (or not cache) it according to the rules you've decided. And then to load everything and combine it together on page loads.

There are a couple ways to do caching & then page loading depending on where you want to cache the cacheable data.

If you want to cache on client side - You can cache the cacheable part of the page in a browser (or native app) cache. Then, on page load, you can fetch the user-purchase data by having the page's Javascript (or native code) make a request(s) to the backend server. The request (or multiple requests depending on how you decide to do this) can fetch the user item purchase status for each item found in the cached part of the page data.

If you want to cache on server side - In this case, you can cache the cacheable part of the page data in Redis/Memcached/your application's memory/etc. - you have a lot of options for specific technologies. Then, when a page is requested, your backend application can load the cached page data from wherever, then fetch the user item purchase status for each item found in the cached page data, and finally combine everything into the data sent to the client to display the page.

In our company's case, we do a mixture of both of these (and by the way, for us the client-side is generally native mobile rather than web - so we have a bit more flexibility on client side caching).

Finally, as a side note:

I'm guessing in your e-commerce platform a user can never "un-buy" something? In this case you may be able to cache that a user "did buy" something even if you can't cache that a user "did not buy" something. This is a good example of where using both client-side and server-side caches can be useful. You can cache most of the page on client-side, but cache this specific information on server-side to speed up the response of the "check if user bought these items" requests made by the client-side code at page load time.

However, since this is getting to be a lot of caching, for this I would personally suggest to consider the complexity/maintenance drawbacks here vs the performance benefit of this caching (which you would want to performance test to see how much it really helps).