Securing high performance and speed for web content delivery relies on smart caching strategies. Caching content is a well-understood principle, but this still doesn’t make smart caching a given. Cache invalidation isn’t easy, but important things rarely are. Varnish can help. 

US election night news coverage during presidential election years are usually “event” TV, so attracting higher-than-normal traffic is expected. But 2020 has created what can only be described as a sustained spike in live video streaming traffic, as vote counts rolled in and revealed many states’ races too close to call. Traffic to news sites more than quadrupled. 

It's cargo-cult fighting time! Today, we are going to look at a ban expression that you probably have used, and maybe even have recommended (gasp!) to your fellow Varnish users:

req.url ~ /

We'll discuss why we use it, why it's good but mostly bad, and how to fix it. Hopefully, along the way, we'll shed some light on some Varnish internals that you can use in other situations.

At the risk of sounding repetitive, cache invalidation is routinely seen, thanks to a now-immortal statement from Phil Karlton, as one of computer science's two most difficult things. 

And it's true: due to the difficult nature of maintaining real-time, up-to-date cache coherency, cache invalidation is a challenge. It's one we've been working on for just about as long as Varnish has existed.

To delve further into how exactly the different components of cache invalidation work with Varnish, here's an excerpt from the Varnish Wiki on this very subject. 

As usual, I'd like to remind you that the Wiki isn't just ours - it's also yours. I encourage you not only to take a look at it but also to contribute to it based on your own Varnish experience.