WEB & API PERFORMANCE
Why is your backend doing work the edge should be handling?
Parsing duplicate query strings, validating tokens, assembling layouts: none of that needs a backend, yet it eats backend cycles anyway. Dynamic payloads, personalized JSON, bot and AI-agent traffic all hit infrastructure sized for something else. Hit ratios drop. Thread pools drain. Latency creeps up in ways that are hard to trace.
Two products, one engine. Varnish Enterprise is a self-managed programmable edge for bare metal or cloud VMs. Varnish Gateway brings the same acceleration natively into Kubernetes.
What's forcing extra work onto the backend?
Three architectural patterns turn manageable traffic into backend overload:
Query string and header variations fragment the cache
A tracking parameter. A session cookie. A header variation. Each one spins up a new cache entry, even when the payload underneath is identical. One response, cached a thousand times over.
→ The fix: normalize the key before the lookup. Strip what doesn't matter, sort what's left. A thousand variations become one entry.
Dynamic views force a full bypass
A page that's 95% identical across users and 5% personalized gets treated as 100% uncacheable. Every request goes to the backend, including the 95% that never changes.
→ The fix: cache the template once. Assemble the personalized slice in memory, at the edge. Cached speed, personalized result, no round trip.
Security validation happens too far back
Standard proxies have nowhere to check a token or enforce a rate limit, so bots and unauthenticated traffic sail through to your microservices. The backend spends compute rejecting requests it should never have seen.
→ The fix: validate tokens and enforce rate limits inside the caching engine itself. Bad traffic dies at the perimeter. Backends only ever see the clean requests.
Cache and routing config live outside your GitOps workflow
A routing rule. A TLS cert. A cache policy. On a standard proxy, changing any of them on Kubernetes means a manual, out-of-band edit.
→ The fix: declare routing and caching as native Kubernetes resources. Same GitOps workflow you already use for everything else. No side channel, no drift.
Does this sound familiar? Origin traffic that never needed a backend, or a config change that has to happen outside your normal workflow: this is what Varnish can fix.
How Varnish solves it
An API endpoint returns the same product catalog to a thousand sessions, each carrying a different tracking parameter or token. A generic cache sees a thousand URLs and forwards every one. Varnish normalizes the key, serves the same payload from cache, and the backend sees exactly one request: the one that built it
Varnish Enterprise
01
Normalize cache keys at the edge |
Query parameters and cookie headers get parsed, sanitized, and sorted before the lookup. Strip the tracking tags, drop the unused cookies, collapse a thousand variations into one clean key. Hit ratios reach 95%+ without adding infrastructure. |
02
Assemble dynamic layouts in memory |
Base HTML gets cached as a compiled template, then merged with a lightweight, user-specific JSON payload in memory at the edge. Personalized pages, cached speed, zero backend round trip. |
03
Validate tokens and enforce rate limits in-process |
JWT verification and distributed rate limits run natively inside the request pipeline. Bad calls get dropped at the perimeter. Backends only ever process clean, pre-authenticated traffic. |
Varnish Gateway
04
Declare routing and caching in native Kubernetes resources |
Ingress routing, TLS certificates, and cache policy get managed as standard Kubernetes Gateway API resources, HTTPRoute included. Delivery logic lives inside the GitOps workflow you already run. |
Why doesn't your current setup already solve this?
Challenge 1
Query and header variations fragment the cache
Every variation in API query strings or client headers treated as a distinct object produces thousands of redundant cache entries from identical payloads. The cache fills with duplicates, and no amount of added capacity moves the hit rate.
Challenge 2
Application-level cache in front of personalization logic
Still needs a backend round trip to assemble the response, simply moving the bottleneck rather then removing it.
Challenge 3
Auth and rate limits enforced in application middleware
Still lets the request reach the backend process before rejection. The compute cost of parsing and routing it is already spent.
Challenge 4
Security has no native home at the edge
Standard proxies offer no in-process mechanism for JWT validation or rate limiting, so security logic lives in application code and runs after the request has already consumed backend resources.
"Moving to Enterprise, VMODs meant that we could use that distributed cache and cluster caching that reduced our loadbalancing complexity, which has optimized performance for cache invalidation and general storage."
Global SRE Lead
Global publishing platform
The numbers
Backends handle less. Edges handle more. Users feel the difference in every interaction.
80%+
50%+
90%+
Choose your performance pathway
Both products share the same core engine. The deployment model adapts to your infrastructure, not the other way around:
Varnish EnterpriseSelf-managed private edge
|
Designed for high-traffic web and API infrastructure on bare metal or cloud VMs. Varnish Enterprise gives you a self-managed programmable edge with full control over routing, security, and caching logic at wire speed. |
Varnish GatewayCloud native Kubernetes ingress
|
Built for containerized workloads on Kubernetes. Varnish Gateway brings the same acceleration natively into your cluster, managed through the same GitOps workflow your team already uses. |
Resources and media
-
Varnish Enterprise Helm Chart deployment
Deployment sets up Varnish as an ephemeral Pod, which may be scheduled to any nodes within the Kubernetes cluster.
-
Clustering with Varnish Enterprise
Effective ways to configure clustering in Varnish Enterprise
-
Introducing the Varnish Gateway
Varnish Gateway is a Kubernetes Gateway API implementation that uses Varnish as the data plane
-
Varnish quick start guide
This quick start guide offers quick installation instructions for Linux distributions, such as Ubuntu, Debian, CentOS and Red Hat Enterprise Linux.
Next steps
Talk to our team to learn more about Varnish Enterprise.
