Een website met veel verkeer verminderde het aantal database-queries voor de trending-page feed van 4.000 per minuut naar minder dan 50 en verlaagde de 95e-percentiel responstijd van 380 ms naar 40 ms door over te stappen van whole-page caching naar fragment caching met Varnish en Edge Side Includes (ESI).

Waarom de site een andere cache-strategie nodig had

De homepage die de meest bekeken clips van de dag toont, ziet er voor bijna elke bezoeker in een regio hetzelfde uit: ongeveer 95 procent van de HTML is identiek voor een miljoen gebruikers, terwijl de resterende 5 procent persoonlijke gegevens bevat, zoals de naam van de ingelogde gebruiker of een zoekveld. Het engineeringteam stond voor twee ongunstige opties:

  • De volledige pagina cachen en het risico lopen verouderde persoonlijke gegevens te tonen aan ingelogde gebruikers.
  • De cache volledig omzeilen en elke aanvraag de database laten belasten.

Beide benaderingen schaadden de gebruikerservaring. Het team koos voor ESI, een techniek waarmee een reverse-proxy een pagina kan samenstellen uit onafhankelijk gecachte fragmenten aan de edge van het netwerk.

Hoe fragment caching werd ingericht

Varnish, de open-source HTTP-accelerator, behandelde de pagina als een skelet met drie vervangbare onderdelen:

  • Videoraster – de kostbare, regio-brede lijst met trending video's. Gecached voor 60 seconden omdat deze vaak verandert, maar hetzelfde is voor elke anonieme bezoeker.
  • Taalschakelaar – een statisch UI-element dat zelden verandert. Gecached voor 24 uur.
  • Header – het enige echt persoonlijke fragment (gebruikersnaam, avatar, meldingen). Nooit gecached; Varnish stuurt de aanvraag elke keer door naar de applicatieserver.

Wanneer een aanvraag binnenkomt, serveert Varnish het gecachte skelet, haalt de twee gecachte fragmenten uit de lokale opslag en voegt de live header vanuit de backend toe.

De cijfers die ertoe doen

Na de overstap:

  • De databasebelasting voor de trending-page daalde van 4.000 queries per minuut naar minder dan 50.
  • De 95e-percentiel latentie daalde van 380 ms naar 40 ms.

Drie praktische lessen uit de uitrol

1. Grace periods verzachten cache misses Wanneer de TTL van een fragment verloopt, zou Varnish normaal gesproken pauzeren om nieuwe inhoud op te halen, wat een latentiepiek veroorzaakt die kan uitmonden in een "thundering herd" van gelijktijdige backend-aanroepen. Door een grace period te configureren, blijft Varnish het verouderde fragment serveren terwijl het op de achtergrond stilletjes de cache ververst. Gebruikers merken geen vertraging; de backend ziet een stabiel en beheersbaar aantal aanvragen.

2. Verwijder cookies voor anonieme fragmenten Cookies die bij elke aanvraag horen, zorgen ervoor dat Varnish elke aanvraag als uniek behandelt, waardoor cache-hits worden tenietgedaan. Het team heeft cookies verwijderd voor het videoraster en de taalschakelaar, waardoor deze fragmenten agressief gecached kunnen worden. Alleen het header-fragment bevat cookies, waardoor personalisatie behouden blijft zonder de cache-efficiëntie op te offeren.

3. Surrogate keys maken instant purging mogelijk Soms moet een video onmiddellijk worden verwijderd, bijvoorbeeld vanwege auteursrechten. Wachten tot de TTL van 60 seconden verloopt, is onacceptabel. Door elk gecached fragment te voorzien van een surrogate key die de onderliggende video-ID's reflecteert, kan het team één enkel purge-commando uitvoeren dat onmiddellijk alle kopieën van een specifieke video op elke edge-node ongeldig maakt. Dit voorkomt een volledige cache-sweep en zorgt ervoor dat de site aan de regels voldoet.

Conclusie: Fragment caching met Varnish en ESI verandert een monolithische, aan de database gebonden pagina in een reeks lichtgewicht, herbruikbare onderdelen, waardoor de backendbelasting en latentie drastisch worden verlaagd terwijl de personalisatie per gebruiker behouden blijft.