Caching

The ICC “Caching” page provides functionality to search and invalidate cache entries managed by the ICC platform. The system handles two types of cache: HTTP cache and Next.js cache.

HTTP Cache

HTTP cache operates on the client side and is shared across all services within the same Watt application. This local application cache runs on the main thread. Cache data is shared across all applications, with each local application cache tracking the global shared cache.

In the top left corner, you can select an application to view its local client cache. All cache entries are grouped by the target origin.

To see an entry detail, unfold the grouped list and click on the entry.

The cache details view displays which route was cached, when it was cached, and when the cache entry will expire.

The “Cache Dependency Tree” shows traces that include calls to the cached route. The blue arrow indicates the current cached API call you are viewing. Yellow arrows represent other cached API calls that are dependent on this entry. When you invalidate the current entry, all entries marked with yellow arrows will automatically be invalidated as well.

You can invalidate a cache entry, which will remove it from a shared cache storage for all clients. All dependent cache entries will also be invalidated automatically. Cache dependency is built on cache tags. For example, if a call to /products/42 returns cache tag products-42 in the response header and a call to /content returns product-42,product-43 cache tags, then /content depends on /products/42 and will be invalidated when /products/42 is invalidated.

Next.js Cache

ICC also supports Next.js caching which happens on the server side. Cache entries are also grouped by the origin. There are two types of Next.js cache entries: components (fetches) and pages.

Next.js components cache entry

Next.js page cache entry