Cache usage

What is cached?

The solution makes heavy use of caching. The guideline we try to follow is, that once the website is warm we should never hit the database or PIM api in the normal product presentation. The data should come from Bizzkit Cache, Ecommerce Search, CDNs and memory caches.

Once the customer moves to the basket and checkout, the backend will start depending on the database directly. But this is usually not an issue since these pages get much less traffic.

We regularly look at traces to see where the time is spent when loading the main pages. If we for instance hit the PIM API on every fresh load of the website, then we consider it a bug that needs to be fixed.

The reason we care about not hitting the database is because in our experience it can not easily be scaled out. We can scale out Redis and add more webserver nodes when we need it.

How is it cached?

Most things are cached using Bizzkit Cache's IMultiLayerCache and with serve stale enabled. This cache will get data in memory when requested and then fall back to a Redis cache that acts as a distributed cache. When the cached value expires and serve stale is enabled it will return the stale value and refresh the cache in the background, so the customer doesn't experience a spike in response time.

There are some things that are not cached in the Bizzkit Cache though. For instance translations for the webshop. These are always loaded into memory by a hosted service that reloads them every X minutes. It is very important that translations do not suddenly get invalidated and removed from memory, which is why they have this special reload-design instead.

The core product data is not cached. Instead it is indexed in Elasticsearch. We find that in general Elasticsearch is fast enough that we don't need to add extra caching on top.