What is Varnish?
Varnish Cache is an HTTP accelerator: a reverse proxy that sits in front of your web servers and keeps responses in memory. When a request arrives that it has seen before, it answers directly and your application never hears about it. Responses come back in well under a millisecond, because serving from memory is all it is doing.
It is configured in its own language, VCL, which is closer to writing a small program than filling in settings. That is the source of both its power and its reputation.
What it changes
The interesting number is not the speed of a cached response. It is the load that never reaches the origin.
A site where most requests are for the same few hundred pages, and where those pages are identical for most visitors, can serve the large majority of its traffic without executing any application code. Your database sees a fraction of the queries. Your application servers stop being the constraint. Traffic spikes hit a cache instead of a runtime.
That is why Varnish tends to arrive after an incident. The pattern is familiar: a page gets shared widely, the site falls over, and someone works out that ninety percent of those requests were for one article that had not changed in a week.
VCL, and why it matters
Most caches let you configure rules. Varnish has you write them.
VCL gives control over what gets cached and for how long, which cookies and headers to ignore when deciding whether two requests are the same, how to normalize requests so they hit the same cache entry, how to handle a failing backend, and how to modify requests and responses as they pass.
That flexibility is genuinely useful, because real sites have awkward requirements that a settings page cannot express. It is also the honest downside: VCL is code. It needs review, testing and someone who understands it, and a subtle mistake in it either caches nothing or, much worse, serves one user's page to another.
When Varnish fits
- Read-heavy sites with shared content. News, catalogs, documentation, marketing sites. The more visitors see the same bytes, the better it works.
- Origin infrastructure you want to protect from spikes, either for cost or for stability.
- Caching rules a CDN's configuration cannot express. This is the strongest reason to run your own: when the logic is genuinely yours.
- Content that must stay in your jurisdiction, where sending it through a third-party network is the thing you are trying to avoid.
When a CDN is the better answer
Worth saying plainly on a page about Varnish.
A CDN puts cached content in many locations near your users. Varnish is a cache in one place, which by default is wherever your origin is. If your visitors are geographically spread and latency is the problem, distribution beats a single fast cache, and a CDN is less to operate.
Which CDN matters less than the decision to use one. Cloudflare, Fastly and Akamai all solve the distribution problem, and for a Swiss or multi-CDN arrangement swiss-cdn.ch covers that side.
The two are not exclusive either. A common arrangement is a CDN at the edge and Varnish in front of the origin, each handling what it is good at.
When it does not fit at all
Personalized pages. If every response differs per user, there is little to share and the cache hit rate collapses. Partial techniques exist and they are work.
Write-heavy applications. Caching helps reads. An API that mostly accepts data gains little.
When nobody can own the VCL. An unmaintained cache configuration ages badly and fails in confusing ways.
What running it involves
- Invalidation is the hard part. Deciding what to cache is easy. Making sure a page updates promptly when the content behind it changes, without flushing everything, is where the real design work sits.
- Memory sizing. The cache lives in RAM. Too small and the hit rate drops without warning; too large and you paid for memory you are not using.
- Cold starts. A restarted Varnish has an empty cache, and every request goes to the origin at once. If the origin cannot take full traffic, restarts need care.
- VCL under version control, reviewed like any other code, because it is.
- Watching the hit rate. A cache quietly missing is worse than no cache: you pay for the hop and get none of the benefit.
Where VSHN fits
VSHN is Switzerland's Varnish Cache Competence Center and works on architecture, VCL design and performance optimization for Varnish deployments.
The first question we usually ask is whether Varnish is the right tool for your situation, because for a distributed audience with straightforward caching rules the answer is often a CDN and less infrastructure. Where the rules are genuinely yours, or the content has to stay put, this is the tool.