A high-traffic video site cut database queries for its trending-page feed from 4,000 per minute to under 50 and dropped its 95th-percentile response time from 380 ms to 40 ms by moving from whole-page caching to fragment caching with Varnish and Edge Side Includes (ESI).

Why the site needed a different cache strategy

The front page that shows the day’s most-watched clips looks the same for almost every visitor in a region: about 95 percent of the HTML is identical for a million users, while the remaining 5 percent carries personal data such as the logged-in user’s name or a search box. The engineering team faced two unattractive options:

  • Cache the entire page and risk serving stale personal data to logged-in users.
  • Bypass the cache entirely and let every request hammer the database.

Both approaches broke the user experience. The team turned to ESI, a technique that lets a reverse-proxy assemble a page from independently cached fragments at the edge of the network.

How fragment caching was wired

Varnish, the open-source HTTP accelerator, treated the page as a skeleton with three replaceable pieces:

  • Video grid – the expensive, region-wide list of trending videos. Cached for 60 seconds because it changes frequently but is the same for every anonymous visitor.
  • Language switcher – a static UI element that rarely changes. Cached for 24 hours.
  • Header – the only truly personal fragment (user name, avatar, notifications). Never cached; Varnish forwards the request to the application server each time.

When a request arrives, Varnish serves the cached skeleton, pulls the two cached fragments from its local store, and inserts the live header from the backend.

The numbers that matter

After the switch:

  • Database load for the trending page fell from 4,000 queries per minute to under 50.
  • 95th-percentile latency dropped from 380 ms to 40 ms.

Three practical lessons from the rollout

1. Grace periods smooth out cache misses When a fragment’s TTL expires, Varnish would normally pause to fetch fresh content, creating a latency spike that can cascade into a “thundering herd” of simultaneous backend calls. By configuring a grace period, Varnish continues to serve the stale fragment while it silently refreshes the cache in the background. Users see no pause; the backend sees a steady, manageable request rate.

2. Strip cookies for anonymous fragments Cookies attached to every request cause Varnish to treat each request as unique, nullifying cache hits. The team stripped cookies for the video grid and language switcher, allowing those fragments to be cached aggressively. Only the header fragment carries cookies, preserving personalization without sacrificing cache efficiency.

3. Surrogate keys enable instant purging Sometimes a video must be removed immediately—e.g., for copyright reasons. Waiting for the 60-second TTL to expire is unacceptable. By tagging each cached fragment with a surrogate key that reflects the underlying video IDs, the team issues a single purge command that instantly invalidates all copies of a specific video across every edge node. This avoids a full cache sweep and keeps the site compliant.

Takeaway: Fragment caching with Varnish and ESI turns a monolithic, database-bound page into a set of lightweight, reusable pieces, slashing backend load and latency while preserving per-user personalization.