Content Delivery Networks are usually thought of for their benefits - they bring content closer to global end-users, reduce stress on origin servers, and add caching and security features that speed up websites and protect them from malicious traffic.
However, CDNs can also add a lot of stress to development teams, and although CDNs are thought of as reducing downtime by bringing content delivery onto their network, if your CDN has many points of presence (PoPs) it can actually add to the time it takes to recover from downtime on your origin server or fix an issue on your site.
This is due to the way CDNs cache content in global servers all over the world and serve that cached content to users. While caching content speeds up page load times, it can have detrimental effects when your website has an issue that needs to be fixed or experiences downtime. Below we review the two main scenarios in which a CDN with many PoPs such could have detrimental effects on website uptime.
Your origin server goes down
This could be due to an issue beyond your control, such as a hosting outage.
- As users around the globe visit your site, the global PoP caches capture and store the error, such as a 503 or 504 error message.
- Until the cache expires (which depends on how long you allow your cache to store pages), users will be served the error page even if the error itself was resolved within a few minutes.
- Different users may see different things depending when the PoP closest to them visited the origin server - pages will be serving error messages for some users, and be functional for others.
Your team makes an error when updating your website
- As users around the globe visit your site, the global PoP caches capture and store the error. It could take over an hour for the change to propagate to all PoP caches, meaning some visitors will report an issue and others will not see it yet. Importantly, the website developers may not even see the error until the PoP closest to them has received the change.
- Once developers see the issue, they attempt to fix it and push the change to the production (live) website. Again, it will take time for the CDN PoPs to propagate the change to all users.
- Because most CDNs do not allow developers to test fixes locally, the first fix may not work and developers would need to push additional fixes.
- This results in an issue that could have been an easy fix taking multiple hours to resolve due to CDN propagation and the inability for developers to test CDN changes locally.
So, how do you avoid these undesirable situations? There are several solutions:
- Use a caching tool that has the ability to serve stale content to users if your origin server is down at the time - Varnish Cache 4 and above, which is available on the Section platform or directly through Varnish Cache, is able to do this.
- Use a CDN with fewer, more powerful PoPs rather than one with thousands of PoPs around the globe. Having fewer PoPs greatly reduces the propagation time, allowing websites to see and fix errors more quickly.
- Use a CDN with an easy, instant cache clear function. Section gives customers the ability to clear the entire cache with one easy click within our portal, with no limit on cache clears and no cost per cache clear.
- Use a CDN which allows you to test changes you make before they go to production. By doing this, websites remove the likelihood that the CDN code will impact changes when they are pushed to production. Section is the only CDN on the market that provides developers with a local CDN environment for testing changes before they go live.
Section’s CDN allows you to quickly propogate changes to our global PoPs, and provides developers with a local testing environment to test changes before they go live. In addition, we provide fully open-source versions of Varnish Cache so you can control all configuration changes. To try us out, sign up for a 14-day free trial.
