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.

Additional Resource: Want to know more about how CDNs work? Here's an article on What CDN is and How it Works.

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 any user requests a piece of content, 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 the same data, the shield server would serve the cached content.

Additional Resource: Interested in learning how to set up your CDN for your Contentstack-powered websites? Refer to our guide on how to set up a Content Delivery Network for Contentstack-powered Websites.

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

Cache Purging

Purging refers to the removal of the cache from the cache servers. Contentstack purges cached data from the cache servers based on the occurrence of certain events.

When a piece of content is published, unpublished, or deleted, Contentstack purges the cache of only the changed content (and some other related content) from the Content Delivery Network (CDN). This ensures that the unchanged cache remains intact, and you hit fewer API requests to the origin server while fetching content.

The following table lists down the different circumstances under which cached content is purged from other cache servers:

Note: The cache of an item can stay on the cache servers for a maximum of 1 year. After that, it is purged automatically.

Determining the Timeouts and Retries for Content Delivery APIs

You can set up timeouts and retries for Content Delivery APIs for your app depending on the time our CDN takes to serve content.

• Requests served by the origin server
  After a purge event, the first request coming to the origin server will take more time than requests served from the cache. This however does not exceed one sec (for regular requests with limited references).
  
• Requests served from cache
  Once the call is cached in the CDN, it can be served in milliseconds. Hence, it is suggested to keep the timeout to as minimum as possible for the time taken by the origin server and three exponential requests on failure.

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 infer from the possible values you may get.

X-Cache

This is the most important of the three cache headers. It helps determine 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 the 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 a piece of content for the first time or after the 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 shows 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 the shield server shows 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 and 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.