Um site de vídeos de alto tráfego reduziu as consultas ao banco de dados para o feed de sua página de tendências de 4.000 por minuto para menos de 50 e diminuiu seu tempo de resposta no percentil 95 de 380 ms para 40 ms, ao migrar do cache de página inteira para o cache de fragmentos com Varnish e Edge Side Includes (ESI).

Por que o site precisava de uma estratégia de cache diferente

A página inicial que mostra os clipes mais assistidos do dia parece a mesma para quase todos os visitantes de uma região: cerca de 95% do HTML é idêntico para um milhão de usuários, enquanto os 5% restantes contêm dados pessoais, como o nome do usuário logado ou uma caixa de pesquisa. A equipe de engenharia enfrentou duas opções pouco atraentes:

  • Fazer o cache da página inteira e correr o risco de servir dados pessoais desatualizados para usuários logados.
  • Ignorar o cache completamente e deixar que cada requisição sobrecarregue o banco de dados.

Ambas as abordagens prejudicavam a experiência do usuário. A equipe recorreu ao ESI, uma técnica que permite que um reverse-proxy monte uma página a partir de fragmentos cacheados de forma independente na borda (edge) da rede.

Como o cache de fragmentos foi implementado

O Varnish, o acelerador HTTP de código aberto, tratava a página como um esqueleto com três peças substituíveis:

  • Grade de vídeos – a lista de vídeos em alta, que é custosa e abrangente para toda a região. Cacheada por 60 segundos porque muda com frequência, mas é a mesma para todos os visitantes anônimos.
  • Seletor de idioma – um elemento de UI estático que raramente muda. Cacheado por 24 horas.
  • Cabeçalho – o único fragmento verdadeiramente pessoal (nome do usuário, avatar, notificações). Nunca é cacheado; o Varnish encaminha a requisição para o servidor de aplicação todas as vezes.

Quando uma requisição chega, o Varnish serve o esqueleto em cache, busca os dois fragmentos cacheados em seu armazenamento local e insere o cabeçalho em tempo real do backend.

Os números que importam

Após a mudança:

  • A carga no banco de dados para a página de tendências caiu de 4.000 consultas por minuto para menos de 50.
  • A latência no percentil 95 caiu de 380 ms para 40 ms.

Três lições práticas do rollout

1. Períodos de carência suavizam as falhas de cache Quando o TTL de um fragmento expira, o Varnish normalmente pausaria para buscar conteúdo novo, criando um pico de latência que pode desencadear um efeito de “manada estrondosa” (thundering herd) de chamadas simultâneas ao backend. Ao configurar um período de carência (grace period), o Varnish continua a servir o fragmento desatualizado enquanto atualiza silenciosamente o cache em segundo plano. Os usuários não percebem pausa; o backend recebe uma taxa de requisições constante e gerenciável.

2. Remova os cookies para fragmentos anônimos Cookies anexados a cada requisição fazem com que o Varnish trate cada uma como única, anulando os acertos de cache (cache hits). A equipe removeu os cookies para a grade de vídeos e o seletor de idioma, permitindo que esses fragmentos fossem cacheados de forma agressiva. Apenas o fragmento do cabeçalho carrega cookies, preservando a personalização sem sacrificar a eficiência do cache.

3. Chaves substitutas permitem a purgação instantânea Às vezes, um vídeo precisa ser removido imediatamente — por exemplo, por motivos de direitos autorais. Esperar o TTL de 60 segundos expirar é inaceitável. Ao marcar cada fragmento em cache com uma chave substituta (surrogate key) que reflete os IDs dos vídeos subjacentes, a equipe emite um único comando de purga que invalida instantaneamente todas as cópias de um vídeo específico em todos os nós de borda (edge nodes). Isso evita uma varredura completa no cache e mantém o site em conformidade.

Conclusão: O cache de fragmentos com Varnish e ESI transforma uma página monolítica e dependente do banco de dados em um conjunto de peças leves e reutilizáveis, reduzindo drasticamente a carga no backend e a latência, ao mesmo tempo em que preserva a personalização por usuário.