Have you used varnishtest? Maybe not, but we’ve just made it a lot easier for you to adopt and put into practice!
I remember very well my first encounter with Varnish. It was this thing with a weird name that worked differently from the tools I had used before. Trying to understand why it was so unfamiliar quickly settled things and Varnish's architecture suddenly became an eye-opener.
When I give a Varnish training, one thing I use when we reach the topic of cache invalidation, is the following quote: "With great power comes great responsibility". Getting things into your cache is only one side of your policy, getting things removed from your cache (invalidation) is another.
I like to emphasize the word “policy”, and make the backends responsible for providing useful information (but that’s a topic for another blog post). When the backend tells you all you need to know, it allows you to not have to handle specific cases in your VCL. This way you can keep a minimal cache policy in Varnish, containing only value-added features, such as robust invalidation schemes, or cache poisoning mitigation.
What is cache poisoning?
Cache poisoning (or cache pollution) is a kind of denial of service attack, which consists of abusing the behavior of a cache and forcing it to keep junk instead of relevant data. If you manage to fill a cache with enough junk, you can significantly slow down the happy path to legitimate content.
Take Varnish for instance. If you start making random requests at a high rate, you can fill the cache with 404 (Not Found) responses if the backends allow Varnish to cache them. For very high traffic websites, however, it would most likely have little effect on fresh content and instead hurt the long tail.