Un sito video ad alto traffico ha ridotto le query al database per il feed della pagina dei trend da 4.000 al minuto a meno di 50 e ha abbassato il tempo di risposta al 95° percentile da 380 ms a 40 ms, passando dal caching dell'intera pagina al caching a frammenti con Varnish ed Edge Side Includes (ESI).

Perché il sito aveva bisogno di una strategia di cache differente

La home page che mostra i clip più visti della giornata appare identica per quasi tutti i visitatori di una regione: circa il 95% dell'HTML è identico per un milione di utenti, mentre il restante 5% contiene dati personali come il nome dell'utente loggato o una barra di ricerca. Il team di ingegneria si è trovato di fronte a due opzioni poco attraenti:

  • Cache l'intera pagina e rischiare di servire dati personali obsoleti agli utenti loggati.
  • Bypassare completamente la cache e lasciare che ogni richiesta sovraccarichi il database.

Entrambi gli approcci compromettevano l'esperienza utente. Il team si è rivolto a ESI, una tecnica che consente a un reverse-proxy di assemblare una pagina partendo da frammenti memorizzati in cache indipendentemente all'edge della rete.

Come è stato implementato il caching a frammenti

Varnish, l'acceleratore HTTP open-source, ha trattato la pagina come uno scheletro composto da tre elementi sostituibili:

  • Griglia video – l'elenco dei video di tendenza, una risorsa costosa che riguarda l'intera regione. Memorizzata in cache per 60 secondi perché cambia frequentemente, ma è identica per ogni visitatore anonimo.
  • Selettore della lingua – un elemento UI statico che cambia raramente. Memorizzato in cache per 24 ore.
  • Header – l'unico frammento veramente personale (nome utente, avatar, notifiche). Mai in cache; Varnish inoltra la richiesta al server applicativo ogni volta.

Quando arriva una richiesta, Varnish serve lo scheletro in cache, recupera i due frammenti memorizzati in cache dal suo store locale e inserisce l'header in tempo reale dal backend.

I numeri che contano

Dopo il passaggio:

  • Il carico del database per la pagina dei trend è sceso da 4.000 query al minuto a meno di 50.
  • La latenza al 95° percentile è scesa da 380 ms a 40 ms.

Tre lezioni pratiche dal rilascio

1. I periodi di grazia attenuano i cache miss Quando il TTL di un frammento scade, Varnish normalmente si interromperebbe per recuperare contenuti freschi, creando un picco di latenza che può degenerare in un effetto "thundering herd" (mandria tonante) di chiamate simultanee al backend. Configurando un periodo di grazia (grace period), Varnish continua a servire il frammento obsoleto mentre aggiorna silenziosamente la cache in background. Gli utenti non riscontrano interruzioni; il backend riceve un tasso di richieste costante e gestibile.

2. Rimuovere i cookie per i frammenti anonimi I cookie allegati a ogni richiesta spingono Varnish a trattare ogni richiesta come unica, annullando i vantaggi della cache. Il team ha rimosso i cookie per la griglia video e il selettore della lingua, consentendo a quei frammenti di essere memorizzati in cache in modo aggressivo. Solo il frammento dell'header trasporta i cookie, preservando la personalizzazione senza sacrificare l'efficienza della cache.

3. Le surrogate keys consentono la purga istantanea A volte un video deve essere rimosso immediatamente, ad esempio per motivi di copyright. Aspettare la scadenza del TTL di 60 secondi è inaccettabile. Taggando ogni frammento in cache con una surrogate key che rifletta gli ID dei video sottostanti, il team può emettere un singolo comando di purga che invalida istantaneamente tutte le copie di un video specifico su ogni nodo edge. Ciò evita una scansione completa della cache e mantiene il sito conforme alle regole.

In sintesi: Il caching a frammenti con Varnish ed ESI trasforma una pagina monolitica e vincolata al database in un insieme di componenti leggeri e riutilizzabili, riducendo drasticamente il carico del backend e la latenza, pur preservando la personalizzazione per ogni utente.