{"id":2781,"date":"2026-09-09T17:20:44","date_gmt":"2026-09-09T20:20:44","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/09\/09\/cloudflare-cache-workers-cache-inteligente-na-edge\/"},"modified":"2026-09-09T17:20:44","modified_gmt":"2026-09-09T20:20:44","slug":"cloudflare-cache-workers-cache-inteligente-na-edge","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/09\/09\/cloudflare-cache-workers-cache-inteligente-na-edge\/","title":{"rendered":"Cloudflare Cache Workers: Cache Inteligente na Edge"},"content":{"rendered":"

O Cloudflare Cache Workers<\/strong> representa hoje um dos pontos de converg\u00eancia mais interessantes entre CDN, edge computing e estrat\u00e9gia de cache program\u00e1vel. Enquanto a Cloudflare consolida uma rede global com presen\u00e7a em mais de 300 cidades<\/strong> e 100 pa\u00edses<\/strong>, processando aproximadamente 1 em cada 5 requisi\u00e7\u00f5es HTTP<\/strong> da internet, o uso de Workers para manipular o cache na borda deixa de ser um recurso experimental e passa a ser pe\u00e7a central em arquiteturas que exigem baixa lat\u00eancia, resili\u00eancia e controle fino sobre o conte\u00fado servido. No cen\u00e1rio brasileiro, onde a dist\u00e2ncia entre os usu\u00e1rios finais e as origens em nuvem p\u00fablica nos Estados Unidos ainda imp\u00f5e desafios de lat\u00eancia, compreender como funciona esse modelo \u00e9 essencial para profissionais de infraestrutura, DevOps e seguran\u00e7a da informa\u00e7\u00e3o.<\/p>\n

Em 2026, o ecossistema de edge computing amadureceu em tr\u00eas frentes complementares: execu\u00e7\u00e3o de c\u00f3digo pr\u00f3xima ao usu\u00e1rio, armazenamento de objetos sem taxas de egress e integra\u00e7\u00e3o nativa com seguran\u00e7a de rede. A Cloudflare atua nas tr\u00eas frentes com um portf\u00f3lio que inclui Workers<\/strong>, R2<\/strong>, D1<\/strong>, KV<\/strong>, Durable Objects<\/strong> e AI Gateway<\/strong>. O an\u00fancio recente da reconstru\u00e7\u00e3o do module registry<\/strong> dos Workers para compatibilidade com Node.js<\/strong>, permitindo aplica\u00e7\u00f5es de at\u00e9 64 mebibytes<\/strong> e usando import.meta<\/strong> com compila\u00e7\u00e3o lazy e caches de c\u00f3digo compartilhados, ampliou significativamente o que \u00e9 poss\u00edvel executar na borda. Paralelamente, a Cloudflare demonstrou que a compress\u00e3o com Zstandard<\/strong> integrada ao Pingora<\/strong> pode economizar petabytes de armazenamento de cache<\/strong> usando o mesmo hardware, um avan\u00e7o direto para quem opera CDNs em escala.<\/p>\n

H\u00e1 ainda dois movimentos que merecem aten\u00e7\u00e3o. O primeiro \u00e9 a ado\u00e7\u00e3o de chaves autom\u00e1ticas p\u00f3s-qu\u00e2nticas<\/strong> no handshake TLS com as origens, protegendo 45 bilh\u00f5es de conex\u00f5es di\u00e1rias<\/strong> contra ataques de “harvest now, decrypt later”. O segundo \u00e9 o suporte a cache tokens<\/strong> no AI Gateway<\/strong>, que permite contabilizar taxas de leitura e escrita de cache em modelos de IA com precis\u00e3o de custo. Esses avan\u00e7os, embora pare\u00e7am dispersos, convergem para o mesmo princ\u00edpio que sustenta o Cloudflare Cache Workers: aproximar dados e l\u00f3gica de execu\u00e7\u00e3o do usu\u00e1rio, reduzir tr\u00e1fego de origem e aplicar pol\u00edticas de cache de forma program\u00e1vel.<\/p>\n

O Workers, lan\u00e7ado originalmente em 2017 como um runtime de JavaScript na borda, evoluiu de fun\u00e7\u00f5es isoladas para uma plataforma completa de desenvolvimento. Hoje, com suporte a JavaScript, WASM e Python<\/strong>, cold start inferior a 1 milissegundo<\/strong> em mais de 275 pontos de presen\u00e7a<\/strong>, e integra\u00e7\u00e3o nativa com armazenamento consistente e eventual, tornou-se a base para produtos como Pages<\/strong>, Zaraz<\/strong> e Stream<\/strong>. Neste post, voc\u00ea vai aprender o que \u00e9 o Cloudflare Cache Workers, como ele se integra \u00e0 Cache API<\/strong>, ao Cache Reserve<\/strong> e ao Tiered Cache<\/strong>, como ele se compara a Lambda@Edge<\/strong> e Vercel Edge<\/strong>, e como arquitetar solu\u00e7\u00f5es de cache program\u00e1vel para o mercado brasileiro, considerando LGPD, lat\u00eancia regional e os recentes an\u00fancios de manuten\u00e7\u00e3o em datacenters como GRU (S\u00e3o Paulo)<\/strong>, ATL (Atlanta)<\/strong> e EWR (Newark)<\/strong>.<\/p>\n

O que h\u00e1 de novo no ecossistema Cloudflare Cache Workers<\/h3>\n

O an\u00fancio mais relevante para quem trabalha com Workers e cache \u00e9 a reconstru\u00e7\u00e3o do module registry<\/strong> para compatibilidade com Node.js<\/strong>. A Cloudflare ativou a compatibilidade por padr\u00e3o, permitindo que desenvolvedores importem m\u00f3dulos do ecossistema Node diretamente em Workers, sem etapas adicionais de polyfill ou bundling complexo. As aplica\u00e7\u00f5es agora podem ter at\u00e9 64 mebibytes<\/strong>, o dobro do limite anterior em muitos cen\u00e1rios. O novo registry \u00e9 baseado em URL<\/strong>, usa import.meta<\/strong> para resolu\u00e7\u00e3o de depend\u00eancias e aplica compila\u00e7\u00e3o lazy<\/strong> \u2014 apenas os m\u00f3dulos realmente utilizados em cada requisi\u00e7\u00e3o s\u00e3o carregados e compilados. O benef\u00edcio direto para o Cloudflare Cache Workers<\/strong> \u00e9 que fun\u00e7\u00f5es de cache podem agora incluir bibliotecas Node legadas com muito menos atrito, mantendo o cold start baixo.<\/p>\n

Outro avan\u00e7o importante vem da pesquisa em compress\u00e3o de cache. O artigo “How we could save petabytes of cache storage with Zstandard and Pingora”<\/strong> demonstrou que \u00e9 poss\u00edvel comprimir o conte\u00fado armazenado no cache da Cloudflare usando Zstandard<\/strong>, reduzindo drasticamente o espa\u00e7o ocupado por objetos est\u00e1ticos e din\u00e2micos sem degradar a lat\u00eancia de entrega. O Pingora<\/strong>, o proxy HTTP\/2 e HTTP\/3 escrito em Rust que substituiu o Nginx na borda da Cloudflare, executa a compress\u00e3o e descompress\u00e3o de forma nativa. Para operadores de CDN, isso significa que o mesmo hardware pode armazenar mais conte\u00fado, reduzindo a press\u00e3o sobre Cache Reserve<\/strong> e R2<\/strong>, e melhorando o hit ratio geral.<\/p>\n

No campo da seguran\u00e7a, o Automatic Key Exchange<\/strong> agora sonda origens compat\u00edveis com TLS 1.3<\/strong> para descobrir quais algoritmos de troca de chaves elas suportam. A partir dessa descoberta, a Cloudflare prioriza o algoritmo mais seguro \u2014 preferindo conex\u00f5es p\u00f3s-qu\u00e2nticas<\/strong> sempre que a origem permitir. Esse mecanismo protege 45 bilh\u00f5es de conex\u00f5es di\u00e1rias<\/strong> e tem impacto direto no cache: conex\u00f5es de origem mais r\u00e1pidas e seguras reduzem o tempo de preenchimento do cache em cen\u00e1rios de miss e diminuem a exposi\u00e7\u00e3o de dados durante o handshake. A integra\u00e7\u00e3o \u00e9 autom\u00e1tica e n\u00e3o exige configura\u00e7\u00e3o adicional, mas merece monitoramento por equipes de seguran\u00e7a.<\/p>\n

O AI Gateway<\/strong> tamb\u00e9m passou a suportar cache tokens<\/strong> em m\u00e9tricas de custo personalizadas. Isso permite que empresas que utilizam modelos de linguagem como Llama<\/strong>, Mistral<\/strong>, Whisper<\/strong> ou GPT<\/strong> contabilizem separadamente leituras e escritas de cache de prompts. No cabe\u00e7alho cf-aig-custom-cost<\/code>, agora \u00e9 poss\u00edvel definir per_cache_read_token<\/code> e per_cache_write_token<\/code>. Quando qualquer uma dessas taxas est\u00e1 presente, o AI Gateway ativa a precifica\u00e7\u00e3o de cache; se omitidas, prevalece o c\u00e1lculo tradicional de tokens de entrada e sa\u00edda. Para arquiteturas que combinam Workers<\/strong>, cache de respostas de IA e Vectorize<\/strong> para RAG, esse n\u00edvel de granularidade \u00e9 essencial para controlar custos e demonstrar ROI.<\/p>\n

Por fim, h\u00e1 as manuten\u00e7\u00f5es programadas em datacenters. No Brasil, o GRU (S\u00e3o Paulo)<\/strong> passar\u00e1 por manuten\u00e7\u00e3o em 15 de setembro de 2026<\/strong> e novamente em 18 de setembro de 2026<\/strong>, com janelas de 06:00 \u00e0s 14:00 UTC<\/strong>. J\u00e1 ATL (Atlanta)<\/strong> e EWR (Newark)<\/strong> ter\u00e3o manuten\u00e7\u00f5es em 14 de setembro de 2026<\/strong>. Durante essas janelas, o tr\u00e1fego pode ser reencaminhado para outros pontos de presen\u00e7a, com possibilidade de pequeno aumento de lat\u00eancia. Para empresas brasileiras que dependem de cache na borda, essas manuten\u00e7\u00f5es s\u00e3o um lembrete \u00fatil de que redund\u00e2ncia geogr\u00e1fica e pol\u00edticas de failover devem fazer parte do planejamento operacional.<\/p>\n

O que \u00e9 Cloudflare Cache Workers e como funciona na pr\u00e1tica<\/h3>\n

O termo Cloudflare Cache Workers<\/strong> descreve a combina\u00e7\u00e3o do runtime de Workers com a Cache API<\/strong> e os servi\u00e7os de armazenamento da Cloudflare para implementar l\u00f3gica de cache customizada na borda. Em vez de depender exclusivamente das regras de cache est\u00e1ticas configuradas no painel \u2014 como cache everything<\/code>, respect existing headers<\/code> ou bypass cache<\/code> \u2014, voc\u00ea pode interceptar cada requisi\u00e7\u00e3o HTTP, inspecionar m\u00e9todo, path, headers, cookies e geolocaliza\u00e7\u00e3o, e decidir dinamicamente se a resposta deve ser servida do cache, buscada na origem, armazenada com TTL espec\u00edfico ou redirecionada para outro recurso. Essa flexibilidade \u00e9 o que transforma a CDN em uma plataforma ativa de entrega, e n\u00e3o apenas em um proxy passivo.<\/p>\n

O funcionamento baseia-se no modelo de event listener<\/strong> do Workers. A fun\u00e7\u00e3o fetch<\/code> \u00e9 acionada para cada requisi\u00e7\u00e3o que chega ao ponto de presen\u00e7a. Dentro dela, o desenvolvedor pode chamar caches.default.match(request)<\/code> para verificar se existe uma c\u00f3pia v\u00e1lida no cache local do PoP. Se houver, a resposta \u00e9 devolvida imediatamente, sem custo de origem. Se n\u00e3o houver, o Worker executa fetch<\/code> para a origem, clona a resposta, armazena no cache com cache.put<\/code> e a retorna ao usu\u00e1rio. O c\u00f3digo \u00e9 executado dentro do isolate<\/strong> do V8, o que permite milhares de inst\u00e2ncias por processo e cold starts abaixo de 1 ms<\/strong>, sem o modelo de container frio das fun\u00e7\u00f5es serverless tradicionais.<\/p>\n

A Cache API<\/strong> opera no n\u00edvel de cada datacenter. Isso significa que um objeto armazenado em S\u00e3o Paulo n\u00e3o est\u00e1 automaticamente dispon\u00edvel em Lisboa ou Nova York; cada PoP mant\u00e9m sua pr\u00f3pria c\u00f3pia local. Para escalar esse cache de forma hier\u00e1rquica, a Cloudflare oferece o Tiered Cache<\/strong>, que agrupa datacenters em camadas e faz com que o primeiro acesso em uma regi\u00e3o busque o conte\u00fado em um PoP intermedi\u00e1rio antes de ir \u00e0 origem. Quando combinado com Workers, o Tiered Cache reduz o tr\u00e1fego de origem em at\u00e9 70%<\/strong> em muitos cen\u00e1rios, porque apenas um PoP por regi\u00e3o faz o miss inicial. J\u00e1 o Cache Reserve<\/strong> estende o cache para o armazenamento de objetos R2<\/strong>, permitindo armazenar grandes volumes por longos per\u00edodos sem custo de egress, com preenchimento autom\u00e1tico a partir da Cache API.<\/p>\n\n\n\n\n\n\n\n\n <<\/tbody>\n<\/table>\n
\n

Sua empresa ainda n\u00e3o usa Cloudflare de forma estrat\u00e9gica?<\/p>\n

A JRT Technology Solutions implementa Cloudflare CDN, WAF, Zero Trust e Workers para empresas que precisam de performance, seguran\u00e7a e escalabilidade.<\/p>\n


\n <\/svg>
\n Falar com especialista
\n <\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

O Cloudflare Cache Workers representa hoje um dos pontos de converg\u00eancia mais interessantes entre CDN, edge computing e estrat\u00e9gia de cache program\u00e1vel. Enquanto a Cloudflare consolida uma rede global com presen\u00e7a em mais de 300 cidades e 100 pa\u00edses, processando aproximadamente 1 em cada 5 requisi\u00e7\u00f5es HTTP da internet, o uso de Workers para manipular … Ler mais<\/a><\/p>\n","protected":false},"author":1,"featured_media":2780,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"iawp_total_views":0,"footnotes":""},"categories":[1721],"tags":[3436],"class_list":["post-2781","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cdn-cloudflare","tag-cloudflare-cache-workers"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t

Recurso<\/th>\nFun\u00e7\u00e3o no ecossistema de cache<\/th>\nIntegra\u00e7\u00e3o com Workers<\/th>\nCaso de uso t\u00edpico<\/th>\n<\/tr>\n<\/thead>\n
Cache API<\/td>\nArmazenamento local no PoP para respostas HTTP<\/td>\nChamadas diretas via caches.default<\/code><\/td>\nCache program\u00e1vel de p\u00e1ginas, APIs e assets<\/td>\n<\/tr>\n
Tiered Cache<\/td>\nCache hier\u00e1rquico em camadas entre PoPs<\/td>\nAutom\u00e1tico, mas influenciado pelas decis\u00f5es do Worker<\/td>\nReduzir tr\u00e1fego de origem em regi\u00f5es com muitos PoPs<\/td>\n<\/tr>\n
Cache Reserve<\/td>\nCache de longo prazo baseado em R2<\/td>\nPreenchimento autom\u00e1tico via Cache API<\/td>\nConte\u00fado grande ou pouco acessado, sem egress<\/td>\n<\/tr>\n