Varnish is a caching server, and a great one at that, that much we already know. But what about the content you don't want to cache? For example, those shopping cart requests and other completely uncacheable API calls?

We can of course handle it, but we've got to be wary of the sirens of the cargo cult because you will often see something like this on the internet:

sub vcl_backend_response {
    # check if the backend response header named
    # "cache-control" contains the word "private"
    if (beresp.http.cache-control ~ "private") {
        # if so, don't cache by limiting the Time-To-Live
        # period to 0 second
        set beresp.ttl = 0s;
    }
}

This is both pretty intuitive, and also very wrong. In this post, we'll explore why it's a bad idea, how to do better, and along the way, we'll try to shine some light on a couple of lesser known features of Varnish.

If you’re familiar at all with Varnish, you know it improves content delivery performance by storing a copy of your content in cache, and every request thereafter is fulfilled by the cached content.

If you've read a few of my blog posts, you probably already know I love the VCL (Varnish Configuration Language) idea, big time. Being able to change the processing logic via code opens a world of possibilities and makes pretty much all other tools feel constrained in their configurations. But...

But, well, VCL is code, and code is scary to a lot of users, and I can understand when you begin with Varnish and only have very limited configuration needs, VCL can feel complicated and some would prefer a simple, declarative language. The good news is that it's totally possible, let's see how we can help!

We, as users, are consuming (and producing) more content than ever, Cisco predicts that “global Internet traffic in 2021 will be equivalent to 127 times the volume of the entire global Internet in 2005. Globally, Internet traffic will reach 30 GB per capita by 2021, up from 10 GB per capita in 2016.”