Putting It All Together - Using Varnish Cache to Manage Dynamic CDN Content - Part 3

In the final installment of this series on managing dynamic CDN content, I will illustrate how Varnish Cache puts together the ideas of direct cache invalidation and TTL management to manage dynamic content. (Check out parts one and two of the series to get the whole story.)

Varnish Cache managing your dynamic content

Because of the high performance nature of Varnish Cache, it is a great resource to manage dynamic content between your CDN and origin servers.

The most common approach is combining direct cache invalidation and TTL management. Using the homepage and website example, we would generate our website as usual with a TTL that matches the responsiveness we want on our CDN, for example 60 seconds. However, in Varnish Cache, we will cache the website for 60 minutes. This means that the CDN will check Varnish Cache for updates every 60 seconds, but Varnish Cache will only check origin once an hour. Varnish Cache is now effectively shielding all website traffic from the origin servers. When the website is updated, a direct invalidation (purge request) is sent to Varnish Cache, which forces an update of a single page. Within 60 seconds, that page will be propagated through the CDN and delivered to the users. So in this configuration, Varnish Cache is being used to shield all website traffic (only one request an hour hits origin), but website updates are able to propagate out within 60 seconds.

An alternative configuration is to use TTL management all the way back to origin. This requires your backend to quickly and efficiently identify and respond to conditional requests using an Etag or Last-Modified value. So in the above example, Varnish Cache will cache the website for only 15 seconds, which is much lower than the CDN TTL value. This means that the CDN will still query Varnish Cache once every 60 seconds for updates, but Varnish Cache will now query the origin every 15 seconds. Since the origin is optimized for conditional requests, the added load to origin will be negligible. Updates to the website will be detected and propagated out within a one-minute window and will not require direct cache invalidation between origin and cache.

In both examples, we use very low TTLs to ensure content responsiveness. If we know that during certain periods of time we are less likely to update content, certain pages are less likely to have content change, or even certain users expect more responsive content, we can vary the TTL values to reflect this. Ensuring proper TTL values on all content is always a good strategy. TTL values do not need to be uniform across all content and Varnish Cache can be leveraged to define these custom TTL values.

Also, it’s important to note the role of Varnish Cache as an origin shield. Varnish Cache will absorb all origin load, and during high load, traffic between Varnish Cache and origin will remain flat and predictable. Varnish Cache can be scaled horizontally to match incoming traffic or TTLs can be adjusted to send less traffic back to origin. This allows you to scale out your caching architecture to multiple POPs, CDNs, and request tiers without having to scale out your actual backend infrastructure.

Varnish Cache is used by businesses and organizations across the world to manage, scale, and shield backend infrastructure. With good uses of the practices in this series, Varnish Cache can continue to manage content previously seen as too challenging or “uncacheable”.

Are you curious to learn more about Varnish Cache and cache invalidation strategies from real use cases? Read our case studies to get detailed insights.

Photo (c) 2016 Peter Trimming used under Creative Commons license.