CDN Interview Questions and Answers

A CDN (content delivery network) is essentially a group of servers that are strategically placed across the globe with the purpose of accelerating the delivery of your static web content. For website owners who have visitors in multiple geographic locations, content will be delivered faster to these users as there is less distance to travel. CDN users also benefit from the ability to easily scale up and down much more easily due to traffic spikes. On average, 80% of a website consist of static resources therefore when using a CDN, there is much less load on the origin server.

CDNs are very useful for a multiple reasons: It simply Decrease Server Load - On average, 80% of a website consist of static resources therefore when using a CDN, there is much less load on the origin server. Make Faster Content Delivery - For website owners who have visitors in multiple geographic locations, content will be delivered faster to these users as there is less distance to travel. 100 Percent Availability - CDN users also benefit from the ability to easily scale up and down much more easily due to traffic spikes.

It increases the parallelism available. (Most browsers will only download 3 or 4 files at a time from any

given site.)
It increases the chance that there will be a cache-hit. (As more sites follow this practice, more users
already have the file ready.)
It ensures that the payload will be as small as possible. (Google can pre-compress the file in a wide
array of formats (like GZIP or DEFLATE). This makes the time-to-download very small, because it is super
compressed and it isn't compressed on the fly.)
It reduces the amount of bandwidth used by your server. (Google is basically offering free bandwidth.)
It ensures that the user will get a geographically close response. (Google has servers all over the
world, further decreasing the latency.)

(Optional) They will automatically keep your scripts up to date. (If you like to "fly by the seat of your

pants," you can always use the latest version of any script that they offer. These could fix security holes, but

generally just break your stuff.)

The origin server is the primary source of your website's data and where your website files are hosted. For example, if you are using DigitalOcean to host your site's files and have chosen data centre in San Francisco, then your origin server would be based in San Francisco. Being limited to one server to deliver files from can be quite inefficient as distance is a contributing factor to latency.

Almost each and every site has HTML, JS, CSS, image, video and font files that do not change much from user to user. To minimize the application load time we should use CDN. Azure Content Delivery Network (CDN) is CDN service provided by Azure Cloud Platform that enables in storing and accessing data on different content servers and locations – used by online or cloud services. It provides: Better performance and user experience for end-users who are far from the destination content source or where there are many intermediary nodes in between to reach the content. Ability to scale to handle instantaneous high load and demand Caching content from publicly available Azure storage blobs Caching web content, images, scripts, and other website content from CDN Enables in caching objects to the CDN that are provided by an Azure cloud service Cache content based on specific query strings Accessing cached content from a custom domain name by mapping the CDN HTTP Endpoint.

Edge servers are the CDN servers used to cache content retrieved from your origin server or storage cluster. Another term often closely related to edge server is point of presence (POP). A POP refers to the physical location of where the edge servers are located. That POP can have multiple edge servers caching content at that location.

Being able to deliver parts of a website from various locations helps decrease the distance between the visitor and the web server, thus reducing latency. This is exactly what CDN edge servers achieve.

When a static file gets cached it can be stored for very long periods of time before it ends up expiring. This can be an annoyance in the event that you make an update to a site however, since the cached version of the file is stored in your visitors' browsers, they may be unable to see the changes made. This is due to the fact that a visitor's browser will locally store a cached copy of your static assets given that your website is configured to leverage browser caching. Cache busting solves the browser caching issue by using a unique file version identifier to tell the browser that a new version of the file is available. Therefore the browser doesn't retrieve the old file from cache but rather makes a request to the origin server for the new file.

Cache busting is useful because it allows your visitors to receive the most recently updated files without having to perform a hard refresh or clear their browser cache. From a developer's point of view, using cache busting is beneficial so that the latest changes can be pushed out and become available to everyone immediately. There are a few methods you can use to take advantage of cache busting:

File name versioning (e.g. style.v2.css )
File path versioning (e.g. /v2/style.css )
Query strings (e.g. style.css?ver=2 )

Both file name versioning and file path versioning are recommended cache busting methods. They do not interfere with any caching mechanisms and can be easily updated to reflect a modified file. If using either file name or file path versioning there will be nothing to configure when using cache busting in conjunction with a CDN.

In the case of a CDN, the edge servers are where the data is cached and stored. Once you have integrated a CDN to work with your website, caching takes place as follows:

1. A visitor in a particular location (e.g. Chicago) makes the first request for a static asset on your site (e.g.

style.css)

2. The asset is retrieved from your origin server and upon being delivered, the asset is cached on the KeyCDN Chicago edge server (i.e. the nearest KeyCDN POP based on that visitor's location).
3. If the same visitor makes a request for the same asset again, the request goes to the CDN POP edge server(s) to check if the asset is already cached. If the request hits an edge server that already has the asset

cached, the visitor receives a response from that edge server. On the other hand, if the request hits a different edge server which doesn't have the asset cached yet, Step 2 is repeated. Once your static assets are cached on all the edge servers for a particular location, all subsequent visitor requests for static assets will be delivered from the edge servers instead of the origin, thus reducing origin load and improving scalability.

Advantage of Azure CDN Better performance and improved user experience. Decrease the load on Original server because files are delivered from the edge server (CDN). Only configuration required to enable feature. Robust and less maintenance. Easy to configure and from resource only. Disadvantage of Azure CDN You need to spend around $0.10 per GB. It doesn’t seem much but comparing it with your regular hosting plan bandwidth, It is too costly. Storing some sensitive files on the CDN network may open potential security vulnerabilities. Because it does not matter what you store at CDN, it will be copied to all distributed servers. Using CDN, you are creating an additional “point of failure”. If the CDN network goes down you may lose website visibility.

Today (almost 4 years later), web scaling involves using Content Delivery Network (CDN) front ends, not only for
static content (html,css,js) but also your (JSON) application data.

Of course, you won't put all your data on your CDN cache, but in practice, a lot of common content won't change often. I suspect that 80% of your REST resources may be cached... Even a

one minute (or 30 seconds) CDN

expiration timeout may be enough to give your central server a new live, and enhance the application responsiveness a lot, since CDN can be geographically tuned... To my knowledge, there is no WebSockets support in CDN yet, and I suspect it would never be. WebSockets are statefull, whereas HTTP is stateless, so is much easily cached. In fact, to make WebSockets CDN-friendly, you may need to switch to a stateless RESTful approach... which would not be WebSockets any more.