A caching layer with Varnish
If your site generates the same pages over and over for different visitors, you are doing the same work thousands of times. A cache in front does that work once and serves the result in microseconds — and Varnish is very good at it.
Varnish sits in front of your web application and keeps a copy of responses in memory. The next request for the same thing is answered from RAM in microseconds, without ever touching your application or database. For read-heavy sites the effect is dramatic — it is the difference between a server straining and one that is bored.
What it caches well
- Pages and assets that are the same for everyone — articles, product pages, images
- Anything expensive to generate but rarely changing
- Traffic spikes — a cached page costs almost nothing to serve a thousand times
What it cannot cache
Varnish caches by URL; it cannot cache a page that is different for every logged-in user, because there is no shared result to keep. Personalised dashboards, carts and account pages bypass the cache. The art is caching the shared 90% and letting the personalised 10% through — mark those responses uncacheable and design the page so the shared shell caches while the personal bits load separately.
Invalidation is the hard part
“There are only two hard things in computing”, and cache invalidation is one of them. A cache that serves stale content after you have updated it is worse than no cache. Set sensible lifetimes, and purge specific URLs when their content changes rather than hoping the TTL is short enough. Get this wrong and users see yesterday’s price.
The HTTPS arrangement
Varnish itself speaks plain HTTP. In practice you put TLS termination in front of it — a reverse proxy handling HTTPS, then Varnish, then your application. So the flow is: nginx (TLS) → Varnish (cache) → app. See where to terminate TLS and TLS certificates.
Varnish or just nginx caching
nginx can cache too, and for simple cases its built-in cache is enough and one less thing to run. Reach for Varnish when you need its power — fine-grained rules, a flexible configuration language, serving stale content while refreshing in the background. For a modest site, start with nginx caching and add Varnish only if you outgrow it.
It needs memory
Varnish keeps its cache in RAM, so give it room — the cache is only as good as what fits. On a dedicated server with plenty of memory that is cheap; size it to your working set. See how much server do you actually need.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base