Contentstack CDN Cache Management

A Content Delivery Network (CDN) ensures that a cache of your content is stored at various locations around the globe. Consequently, whenever there is a page request, the content is served from the cache of the nearest CDN server, rather than the origin server, ensuring quicker content delivery. Learn more about how CDNs work.

How CDN Cache Works in Contentstack

The CDN is always up-to-date. It ensures that the cache is always fresh through purging old data and caching new data.

When a piece of content is requested by any user, the nearest CDN server checks if it has a cached copy of the requested content. If not, it checks with the shield server. And, if the shield server does not have the cache of the requested content, it fetches the content from the origin server.

A shield server is an extra layer of caching that reduces the load on the origin server. It is located near the origin server, and it saves the cache of content that it serves to any CDN server. So, if any other CDN server requests for the same data, the shield server would serve the cached content.

This ensures that content is always available and is delivered even in cases of high visitor traffic, intermittent spikes as well as server outages, resulting in better customer experience and satisfaction.

Cache Purging

Purging refers to the removal of the cache from the CDN servers and the shield server.

Cache is purged in the following three scenarios:

  • When an entry is updated, deleted, or unpublished:
    When any entry of your stack is updated, deleted, or unpublished, the cache (on CDN as well as shield servers) of all entries in that stack is purged instantly.
  • When an asset is updated, deleted, or unpublished:
    When any asset of your stack is updated, deleted, or unpublished, the cache (on CDN as well as shield servers) of all assets and entries in that stack is purged instantly.
  • Automatic purging after 24 hours:
    A cached copy of your content stays on the CDN and the shield server for a maximum period of 24 hours from the time of fetching the data. Post 24 hours, the server purges the cached copy automatically.

Understanding Cache Header Response

If you observe that your website is experiencing some delays in serving content, it might be a good idea to check if the content is being served from the CDN’s local data center, shield data center, or through Contentstack’s origin server. This can be done by checking the HIT and MISS cache headers in the response of your API request.

An example of cache headers is given below:

X-Served-By: cache-lxx8483, cache-axs21008-AMS
X-Cache: HIT, MISS
X-Cache-Hits: 1, 0

Let’s learn about these three headers and what to infer from the possible values that you may get.

X-Cache

This is the most important of the three cache headers. It helps in determining if the request was served from the CDN’s local data center, shield data center, or Contentstack’s origin server.
It usually has two values (for example, ‘X-Cache: MISS, MISS’). The first value indicates if the cache is available in the shield server and second indicates if it is available in the local cache server.

Let’s understand the possible values that you can get for this header and what it means.

  • X-Cache: MISS, MISS
    MISS, MISS indicates that the cache for the requested object was neither available in the shield server nor in the local cache node. The content is being delivered from Contentstack’s server. This is usually the case when requesting for a piece of content for the first time, or after purge. 
  • X-Cache: MISS, HIT
    MISS, HIT indicates that the cache was available and served from the local cache node. The ‘MISS’ as the first value here does not suggest that the cache is not available in the shield server (if the cache is available in the local node, it should be available in the shield server). It is showing the state when it was queried the last time. Its value is not updated simply because the request was served from the local node, and didn’t reach the shield server to get the updated state.
  • X-Cache: HIT, MISS
    HIT, MISS indicates that the cache for the requested object was available and served from the shield server since it was not available in the local cache node. 
  • X-Cache: HIT, HIT
    HIT, HIT indicates that the cache was available and served from the local cache node. The ‘HIT’ as the first value for shield server is showing the state when it was queried (and served from the shield server) the last time. Its value is not updated simply because the request was served from the local node, and didn’t reach the shield server to get the updated state. 

X-Cache-Hits

This header, just like the ‘X-Cache’ header, helps in determining if the request was served from the CDN’s local data center, shield data center, or Contentstack’s origin server. 

    0, 0 indicates MISS, MISS
    0, 1 indicates MISS, HIT
    1, 0 indicates HIT, MISS
    1, 1 indicates HIT, HIT

    X-Served-By

    This header provides the IDs of the shield server as well as the local cache node where the request is looking for data.

    Note: When you see only one set of values, instead of two, it means that the closest local cache node is part of the shield server.

    Was this article helpful?
    top-arrow