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.
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.
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:
|Module||Event||Cache purged of|
|Stack access token|
Note: Cache of an item can stay on the cache servers for a maximum of 1 year. After that, it is purged automatically.
You can set up timeouts and retries for Content Delivery APIs for your app depending on the time our CDN takes to serve content.
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.
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.
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
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.