Cloudflare Cache Workers: Cache Inteligente na Edge

O Cloudflare Cache Workers representa hoje um dos pontos de convergência mais interessantes entre CDN, edge computing e estratégia de cache programável. Enquanto a Cloudflare consolida uma rede global com presença em mais de 300 cidades e 100 países, processando aproximadamente 1 em cada 5 requisições HTTP da internet, o uso de Workers para manipular o cache na borda deixa de ser um recurso experimental e passa a ser peça central em arquiteturas que exigem baixa latência, resiliência e controle fino sobre o conteúdo servido. No cenário brasileiro, onde a distância entre os usuários finais e as origens em nuvem pública nos Estados Unidos ainda impõe desafios de latência, compreender como funciona esse modelo é essencial para profissionais de infraestrutura, DevOps e segurança da informação.

Em 2026, o ecossistema de edge computing amadureceu em três frentes complementares: execução de código próxima ao usuário, armazenamento de objetos sem taxas de egress e integração nativa com segurança de rede. A Cloudflare atua nas três frentes com um portfólio que inclui Workers, R2, D1, KV, Durable Objects e AI Gateway. O anúncio recente da reconstrução do module registry dos Workers para compatibilidade com Node.js, permitindo aplicações de até 64 mebibytes e usando import.meta com compilação lazy e caches de código compartilhados, ampliou significativamente o que é possível executar na borda. Paralelamente, a Cloudflare demonstrou que a compressão com Zstandard integrada ao Pingora pode economizar petabytes de armazenamento de cache usando o mesmo hardware, um avanço direto para quem opera CDNs em escala.

Há ainda dois movimentos que merecem atenção. O primeiro é a adoção de chaves automáticas pós-quânticas no handshake TLS com as origens, protegendo 45 bilhões de conexões diárias contra ataques de “harvest now, decrypt later”. O segundo é o suporte a cache tokens no AI Gateway, que permite contabilizar taxas de leitura e escrita de cache em modelos de IA com precisão de custo. Esses avanços, embora pareçam dispersos, convergem para o mesmo princípio que sustenta o Cloudflare Cache Workers: aproximar dados e lógica de execução do usuário, reduzir tráfego de origem e aplicar políticas de cache de forma programável.

O Workers, lançado originalmente em 2017 como um runtime de JavaScript na borda, evoluiu de funções isoladas para uma plataforma completa de desenvolvimento. Hoje, com suporte a JavaScript, WASM e Python, cold start inferior a 1 milissegundo em mais de 275 pontos de presença, e integração nativa com armazenamento consistente e eventual, tornou-se a base para produtos como Pages, Zaraz e Stream. Neste post, você vai aprender o que é o Cloudflare Cache Workers, como ele se integra à Cache API, ao Cache Reserve e ao Tiered Cache, como ele se compara a Lambda@Edge e Vercel Edge, e como arquitetar soluções de cache programável para o mercado brasileiro, considerando LGPD, latência regional e os recentes anúncios de manutenção em datacenters como GRU (São Paulo), ATL (Atlanta) e EWR (Newark).

O que há de novo no ecossistema Cloudflare Cache Workers

O anúncio mais relevante para quem trabalha com Workers e cache é a reconstrução do module registry para compatibilidade com Node.js. A Cloudflare ativou a compatibilidade por padrão, permitindo que desenvolvedores importem módulos do ecossistema Node diretamente em Workers, sem etapas adicionais de polyfill ou bundling complexo. As aplicações agora podem ter até 64 mebibytes, o dobro do limite anterior em muitos cenários. O novo registry é baseado em URL, usa import.meta para resolução de dependências e aplica compilação lazy — apenas os módulos realmente utilizados em cada requisição são carregados e compilados. O benefício direto para o Cloudflare Cache Workers é que funções de cache podem agora incluir bibliotecas Node legadas com muito menos atrito, mantendo o cold start baixo.

Outro avanço importante vem da pesquisa em compressão de cache. O artigo “How we could save petabytes of cache storage with Zstandard and Pingora” demonstrou que é possível comprimir o conteúdo armazenado no cache da Cloudflare usando Zstandard, reduzindo drasticamente o espaço ocupado por objetos estáticos e dinâmicos sem degradar a latência de entrega. O Pingora, o proxy HTTP/2 e HTTP/3 escrito em Rust que substituiu o Nginx na borda da Cloudflare, executa a compressão e descompressão de forma nativa. Para operadores de CDN, isso significa que o mesmo hardware pode armazenar mais conteúdo, reduzindo a pressão sobre Cache Reserve e R2, e melhorando o hit ratio geral.

No campo da segurança, o Automatic Key Exchange agora sonda origens compatíveis com TLS 1.3 para descobrir quais algoritmos de troca de chaves elas suportam. A partir dessa descoberta, a Cloudflare prioriza o algoritmo mais seguro — preferindo conexões pós-quânticas sempre que a origem permitir. Esse mecanismo protege 45 bilhões de conexões diárias e tem impacto direto no cache: conexões de origem mais rápidas e seguras reduzem o tempo de preenchimento do cache em cenários de miss e diminuem a exposição de dados durante o handshake. A integração é automática e não exige configuração adicional, mas merece monitoramento por equipes de segurança.

O AI Gateway também passou a suportar cache tokens em métricas de custo personalizadas. Isso permite que empresas que utilizam modelos de linguagem como Llama, Mistral, Whisper ou GPT contabilizem separadamente leituras e escritas de cache de prompts. No cabeçalho cf-aig-custom-cost, agora é possível definir per_cache_read_token e per_cache_write_token. Quando qualquer uma dessas taxas está presente, o AI Gateway ativa a precificação de cache; se omitidas, prevalece o cálculo tradicional de tokens de entrada e saída. Para arquiteturas que combinam Workers, cache de respostas de IA e Vectorize para RAG, esse nível de granularidade é essencial para controlar custos e demonstrar ROI.

Por fim, há as manutenções programadas em datacenters. No Brasil, o GRU (São Paulo) passará por manutenção em 15 de setembro de 2026 e novamente em 18 de setembro de 2026, com janelas de 06:00 às 14:00 UTC. Já ATL (Atlanta) e EWR (Newark) terão manutenções em 14 de setembro de 2026. Durante essas janelas, o tráfego pode ser reencaminhado para outros pontos de presença, com possibilidade de pequeno aumento de latência. Para empresas brasileiras que dependem de cache na borda, essas manutenções são um lembrete útil de que redundância geográfica e políticas de failover devem fazer parte do planejamento operacional.

O que é Cloudflare Cache Workers e como funciona na prática

O termo Cloudflare Cache Workers descreve a combinação do runtime de Workers com a Cache API e os serviços de armazenamento da Cloudflare para implementar lógica de cache customizada na borda. Em vez de depender exclusivamente das regras de cache estáticas configuradas no painel — como cache everything, respect existing headers ou bypass cache —, você pode interceptar cada requisição HTTP, inspecionar método, path, headers, cookies e geolocalização, e decidir dinamicamente se a resposta deve ser servida do cache, buscada na origem, armazenada com TTL específico ou redirecionada para outro recurso. Essa flexibilidade é o que transforma a CDN em uma plataforma ativa de entrega, e não apenas em um proxy passivo.

O funcionamento baseia-se no modelo de event listener do Workers. A função fetch é acionada para cada requisição que chega ao ponto de presença. Dentro dela, o desenvolvedor pode chamar caches.default.match(request) para verificar se existe uma cópia válida no cache local do PoP. Se houver, a resposta é devolvida imediatamente, sem custo de origem. Se não houver, o Worker executa fetch para a origem, clona a resposta, armazena no cache com cache.put e a retorna ao usuário. O código é executado dentro do isolate do V8, o que permite milhares de instâncias por processo e cold starts abaixo de 1 ms, sem o modelo de container frio das funções serverless tradicionais.

A Cache API opera no nível de cada datacenter. Isso significa que um objeto armazenado em São Paulo não está automaticamente disponível em Lisboa ou Nova York; cada PoP mantém sua própria cópia local. Para escalar esse cache de forma hierárquica, a Cloudflare oferece o Tiered Cache, que agrupa datacenters em camadas e faz com que o primeiro acesso em uma região busque o conteúdo em um PoP intermediário antes de ir à origem. Quando combinado com Workers, o Tiered Cache reduz o tráfego de origem em até 70% em muitos cenários, porque apenas um PoP por região faz o miss inicial. Já o Cache Reserve estende o cache para o armazenamento de objetos R2, permitindo armazenar grandes volumes por longos períodos sem custo de egress, com preenchimento automático a partir da Cache API.