WEB & API PERFORMANCE
Why is your backend doing work the edge should be handling?
Compute cycles spent parsing duplicate query strings, validating tokens, and assembling layouts that haven't changed are cycles not spent on the work that actually requires a backend.
Dynamic payloads, complex client headers, personalised JSON responses, and unauthenticated API traffic all hit backends that were never designed to absorb that volume. Cache hit ratios stay low, origin thread pools drain, and latency creeps up in ways that are hard to diagnose but easy for users to feel.
Where the performance gap opens up
Three architectural patterns turn manageable traffic into backend overload:
Query string and header variations fragment the cache
Treating every variation in API query strings or client headers as a distinct cache object turns identical payload requests into thousands of redundant entries. Cache hit ratios collapse and memory efficiency degrades.
Dynamic views force total bypasses
When user-specific or localised elements force a cache bypass, the entire request goes to the backend. A page that is 95% identical across users gets treated as uncacheable because of the 5% that varies.
Security validation happens too far back
Unauthenticated API requests, bots, and abusive traffic that should be stopped at the perimeter instead reach microservices. Backends spend compute on requests they should never process, draining thread pools and introducing latency for legitimate users.
What backend overload costs your teams
The impact lands differently depending on where you sit:
Web performance engineer
Low cache hit ratios mean more origin requests, higher infrastructure costs, and latency that compounds across every user interaction and shows up in revenue, not just dashboards.
API platform lead
Unauthenticated requests and bot traffic that reaches microservices consumes compute that should be reserved for legitimate API consumers. Rate limiting and token validation implemented in application code drains origin thread pools under any meaningful load spike.
Kubernetes platform engineer
Legacy proxies are operational black boxes. Changing routing logic, TLS termination, or cache policy requires manual configuration changes outside the GitOps workflow your team already uses for everything else.
Why standard proxies don't solve this
Challenge 1
Query parameters 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. Memory fills with duplicates and hit rates stay low regardless of cache size.
Challenge 2
Dynamic views force full bypasses
Personalised or localised elements force teams to bypass caching entirely for affected endpoints, routing everything to the origin rather than finding a way to cache the parts that don't change.
Challenge 3
Header variations waste edge memory
Variations in standard client headers cause proxies to store duplicate copies of matching backend payloads. The cache grows without the hit rate improving.
Challenge 4
Security has no native home at the edge
Standard proxies offer no in-process mechanism for JWT validation or rate limiting. Security logic lives in application code, which means it executes after the request has already consumed backend resources.
"Varnish is the cornerstone of how we handle scale"
Global streaming service
How Varnish solves it
Two products address this problem depending on your infrastructure topology:
Varnish Enterprise
01
Normalise cache keys at the edge |
Incoming query parameters and cookie headers are parsed, sanitised, and sorted before the cache lookup occurs. Non-functional tracking tags and unused cookies are stripped, collapsing thousands of request variations into a single clean cache key. Cache hit ratios reach 95%+ without scaling infrastructure. |
02
Assemble dynamic layouts in memory |
Generic content templates are decoupled from user-specific presentation. Base HTML pages are cached as compiled templates, then merged with lightweight user-specific JSON payloads in memory at the edge during delivery. Personalised pages at cached speeds — without a backend round trip. |
03
Validate tokens and enforce rate limits in-process |
JWT signature verification and distributed rate-limiting rules run natively inside the caching engine's request pipeline. Unauthorised and abusive calls are dropped at the perimeter. Backend services only process clean, pre-authenticated traffic. |
Varnish Gateway
04
Declare routing and caching in native Kubernetes resources |
Ingress routing, TLS certificates, and custom cache policies are managed via standard Kubernetes Gateway API resources including HTTPRoute. Delivery logic lives inside your existing GitOps workflow — no out-of-band proxy management, no configuration drift, no manual changes outside version control. |
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 containerised 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.
