We at Varnish Software are pretty keen on new technologies, experimentation and the sense of learning in and from a community (Varnish Cache, after all, is open source and has a thriving community supporting it). The bigger the community, the more there is to learn and be inspired by.

If your content ever changes you’ll need some way to make sure the updated content reaches the users. The traditional way of doing this is to devise some sort of cache invalidation. You’ll hook it into your CMS and when content changes a HTTP PURGE or REFRESH call goes out to the Varnish Cache servers and the stale content is discarded. This is all pretty nice. There is one problem: if you should ever lose a PURGE request then your content will stay stale for as long as your TTL allows. You have a few options: 

There is a reason why people install Varnish Cache in their servers. It’s all about the performance. Delivering content from Varnish is often a thousand times faster than delivering it from your web server. As your website grows, and it usually grows significantly if your cache hit rates are high, you’ll rely more and more on Varnish to deliver the brunt of the requests that are continuously flowing into your infrastructure.