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 cache servers. Contentstack purges cached data from the cache servers based on the occurrence of certain events.

The following table lists down the different circumstances under which cached content is purged:

ModuleEventCache purged of
Entry
  • Publish
  • Unpublish
  • All entries of the stack that have been published to that specific environment
Entry
  • Delete
  • All entries of the stack that have been published to all environments
Asset
  • Publish
  • Unpublish
  • All entries and assets of the stack that have been published to that specific environment

    Note: Cache of download URLs of assets is not purged.
Asset
  • Delete
  • Download URLs of the asset
  • All entries and assets of all environments in the stack 
Stack access token
  • Reset
  • All entries, assets, and download URLs (of assets) of all environments in the stack
Delivery token
  • Delete
  • All entries and assets of the stack published to that specific environment
Delivery token
  • Update (Environment change)
  • Cache of all entries and assets of the stack published to the earlier environment
Stack
  • Delete
  • Cache of all entries, assets, and download URLs (or assets) of of all environments in the stack
Environment
  • Update (Name change)
  • Delete
  • Cache of all entries and assets of the stack published to that specific environment
Locale
  • Update
  • Delete
  • Cache of all entries and assets of the stack published to that specific locale
Global Field
  • Create
  • All global fields of the stack
Global Field
  • Update
  • Delete
  • All global fields of the stack
  • All content types of the stack (If the global field is referred in a content type)
  • Cache of all entries of all environments in the stack (If the global field is referred in a content type)
Content Type
  • Create
  • All content types of the stack
Content Type
  • Update
  • Delete
  • All content types of the stack
  • All entries of the stack

Note: 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 origin server
    After a purge event, the first request coming to the origin server will take more time as compared to requests served from cache. This however does not exceed 1 sec (for normal 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 with respect to the time taken by the origin server and 3 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 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