As they say, in computer science there are two hard problems: naming things, cache invalidation and off by one errors. Ba-dum-bum.

At Culture Foundry we use caches extensively. Sometimes they are built into the application frameworks. Other times they are external caching systems like varnish or Cloudfront. One thing we’ve learned is that if you have mulitple layers of these external caches, it is very helpful to be able to access each of them indvidually. This lets you get to different layers of your cake (err, application), which makes troubleshooting easier. Assume you had an application running on multiple servers behind several layers of indirection:

User -> Cloudfront -> ELB -> varnish cache1,2,3 -> webserver1,2,3

If you are having a caching issue, have DNS names pointing to each of these layers. You’ll definitely have one pointing to Cloudfront (which is how normal users will access the application), and the ELB will have one provided by AWS. Each of the webservers should have a DNS name as well. You need to configure your web server to listen for those various DNS names and respond accordingly. You may have the following domain names for each layer:

• Cloudfront: www.example.com
• ELB: elb.example.com
• varnish cache 1: varnish1.example.com
• varnish cache 2: varnish2.example.com
• webserver1: webserver1.example.com
• webserver2: webserver2.example.com
• …

Now, if you receive feedback saying “the website is showing an outdated logo” you can visit each layer of the caching system and see where the issue pops up (is the issue present at the ELB? is it happening on the origin server? which one?). You could troubleshoot by sshing to each server and looking at log files, but using your browser to test each layer is much easier than juggling four or more terminal windows and tailing different logfiles. You can also make this available to non developers to help troubleshoot.

Since these DNS names are public it may mean that users access them. You probably don’t want that, and should be rigorous about only displaying the Cloudfront DNS on the application, and using relative URLs. If you want to make extra sure that there is no unauthorized access to other layers of your application, then you can lock down access using security groups (or a similar construct if you are not running on AWS) and only allow known IP addresses to access the layers behind your outermost cache.