O Que É a Invalidação de Cache de CDN

Introdução à cache de CDN

Uma Content Delivery Network (CDN) funciona armazenando em cache cópias do seu conteúdo em servidores edge em todo o mundo e servindo-as aos utilizadores a partir do servidor mais próximo, em vez de cada pedido ir até ao seu servidor de origem. Isto reduz drasticamente a latência e acelera o carregamento do site para os utilizadores, independentemente de onde se encontrem. No entanto, a cache traz um desafio fundamental — como garantir que os utilizadores veem sempre a versão mais recente do conteúdo quando faz alterações no site.

A invalidação de cache é o processo de remover ou substituir conteúdo desatualizado da cache da CDN. Phil Karlton disse uma vez que existem apenas duas coisas difíceis na ciência da computação: nomear coisas e a invalidação de cache. Esta afirmação ilustra na perfeição a complexidade da gestão de cache, porque cada decisão errada pode resultar em utilizadores a ver conteúdo desatualizado ou no servidor de origem a ser sobrecarregado desnecessariamente porque a cache é limpa de forma demasiado agressiva.

Como funciona a cache de CDN

Quando um utilizador solicita pela primeira vez um recurso que não está em cache, a CDN reencaminha o pedido para o servidor de origem, recebe a resposta e armazena uma cópia no seu servidor edge. Todos os pedidos subsequentes para o mesmo recurso a partir do mesmo servidor edge são servidos diretamente da cache, sem contactar a origem. O servidor de origem controla o comportamento da cache através de cabeçalhos HTTP como Cache-Control, Expires, ETag e Last-Modified.

Cabeçalhos HTTP fundamentais para a cache

• Cache-Control: max-age=3600 - o recurso permanece fresco durante os próximos 3600 segundos (1 hora)
• Cache-Control: s-maxage=86400 - específico para caches partilhadas (CDN), com prioridade sobre max-age
• Cache-Control: no-cache - a cache tem de revalidar com a origem antes de servir
• Cache-Control: no-store - o recurso nunca deve ser colocado em cache
• ETag - identificador único da versão do recurso para revalidação
• Vary - determina por que cabeçalhos diferem as versões em cache

Compreender estes cabeçalhos é fundamental, pois definem as regras pelas quais a CDN decide se serve a versão em cache ou se pede uma nova à origem. Cabeçalhos mal configurados são a causa mais comum de problemas com conteúdo desatualizado ou de pedidos desnecessariamente frequentes à origem.

Purga de cache - limpeza manual da cache

A purga de cache é a forma mais direta de remover conteúdo da cache da CDN. A maioria dos fornecedores de CDN oferece API e painel para acionar manualmente operações de purga. Pode limpar um único URL, um grupo de URLs por padrão (wildcard purge) ou a cache completa de todos os recursos. Cada abordagem tem vantagens e desvantagens consoante a situação.

Tipos de operações de purga

A purga de um único URL é o método mais preciso e rápido, pois visa exatamente um recurso. Use-a quando atualizar uma página ou ficheiro. A purga por wildcard elimina todos os recursos que correspondem a um determinado padrão; por exemplo, /blog/* elimina todas as páginas do blog da cache. Isto é útil ao atualizar um maior número de páginas sem querer limpar a cache completa. A purga total elimina absolutamente tudo da cache e só deve ser usada em situações urgentes, pois aumenta temporariamente a carga no servidor de origem enquanto a cache é reconstruída.

As operações de purga propagam-se normalmente pela rede da CDN em 1 a 30 segundos, consoante o fornecedor e a dimensão da rede. A purga na rede Cloudflare propaga-se em cerca de 30 segundos a nível global, enquanto a AWS CloudFront pode exigir até 15 minutos para invalidações por wildcard. Tenha sempre este atraso em mente ao fazer alterações em produção e ao testar se a nova versão já está visível.

Estratégias de TTL

O Time-To-Live (TTL) determina durante quanto tempo a CDN considera o conteúdo em cache como fresco antes de pedir uma nova versão à origem. Definir corretamente o TTL é um equilíbrio entre desempenho (TTL mais longo = menos pedidos à origem) e frescura do conteúdo (TTL mais curto = alterações visíveis mais depressa). Não existe um TTL universalmente correto, pois depende do tipo de conteúdo e da frequência com que muda.

TTL recomendado por tipo de conteúdo

• Ativos estáticos (JS, CSS, tipos de letra) - 1 ano (31536000s) com versionamento de ficheiros
• Imagens - 30 dias (2592000s) com revalidação por ETag
• Páginas HTML - 5 minutos a 1 hora consoante o conteúdo dinâmico
• Respostas de API - 0 a 60 segundos consoante os dados
• Favicon e robots.txt - 1 dia (86400s)

A diretiva stale-while-revalidate é uma excelente estratégia que permite à CDN servir conteúdo desatualizado aos utilizadores enquanto, em simultâneo, pede uma nova versão à origem em segundo plano. Isto significa que o utilizador nunca espera pelo servidor de origem, mas verá a nova versão no pedido seguinte. Por exemplo, Cache-Control: max-age=60, stale-while-revalidate=3600 significa que o conteúdo está fresco durante 60 segundos, mas pode ser servido da cache durante a hora seguinte enquanto é atualizado em segundo plano.

Versionamento de recursos

O versionamento de recursos é a estratégia mais elegante para resolver o problema da invalidação de cache, pois elimina completamente a necessidade de operações de purga explícitas. Em vez de alterar o conteúdo do ficheiro no mesmo URL, cada nova versão recebe um novo URL, o que significa que a CDN serve automaticamente a nova versão, pois trata-a como um recurso completamente novo que ainda não está em cache.

Métodos de versionamento

O hash de conteúdo no nome do ficheiro é o método mais popular. Ferramentas de build como Webpack, Vite e Next.js adicionam automaticamente o hash de conteúdo ao nome do ficheiro; por exemplo, style.a1b2c3d4.css. Quando o CSS muda, o hash muda e é gerado um novo ficheiro com um novo nome. A versão antiga permanece em cache, mas já ninguém a referencia, pois o HTML aponta agora para o novo ficheiro.

O versionamento por query string (style.css?v=1.2.3) é uma abordagem mais simples, mas menos fiável, pois alguns fornecedores de CDN ignoram as query strings ao colocar em cache. Use-a apenas se não conseguir alterar o nome do ficheiro. O versionamento por caminho (/v2/style.css) é outra opção que funciona de forma fiável com todos os fornecedores de CDN, mas exige mais configuração no servidor.

Quando invalidar a cache

Saber quando invalidar a cache é tão importante como saber como o fazer. Os cenários mais comuns que exigem invalidação incluem a publicação de uma nova versão do site no servidor de alojamento, a correção de um erro crítico no conteúdo, a remoção de conteúdo sensível publicado acidentalmente e a alteração de preços ou disponibilidade de produtos numa loja de comércio eletrónico. Em todos estes casos, os utilizadores têm de ver o conteúdo atualizado o mais depressa possível.

Boas práticas de invalidação

• Automatize - integre a purga de cache no pipeline de CI/CD para invalidação automática em cada deploy
• Seja preciso - vise URLs específicos em vez da purga total sempre que possível
• Use versionamento - para ativos estáticos elimina completamente a necessidade de invalidação manual
• Monitorize - acompanhe o cache hit ratio para descobrir problemas de configuração
• Teste - verifique os cabeçalhos com curl -I para confirmar que a cache funciona como esperado
• Documente - registe os valores de TTL e a estratégia de invalidação para cada tipo de conteúdo

Problemas comuns e soluções

Um dos problemas mais comuns é o chamado stale content, em que os utilizadores veem conteúdo desatualizado apesar das alterações que fez no servidor de origem. A causa é normalmente um TTL demasiado longo sem um mecanismo de invalidação. A solução é a combinação de um TTL razoável com operações de purga automatizadas no deploy. Outro problema comum é o cache stampede, em que, depois de o TTL expirar para um recurso popular, centenas de pedidos concorrentes atingem o servidor de origem em simultâneo. A solução é o request coalescing, em que a CDN envia apenas um pedido à origem enquanto retém todos os outros pedidos até receber a resposta.

O problema de versões de conteúdo diferentes em servidores edge diferentes (inconsistência de cache) surge porque uma operação de purga não se consegue propagar a todos os servidores em simultâneo. Durante o curto período após a purga, alguns utilizadores verão a versão antiga e outros a nova. Para alterações críticas, use o mecanismo de versionamento de URLs, que garante consistência, pois cada utilizador acede a uma versão do recurso definida com exatidão.