{"id":1490,"date":"2026-07-12T17:19:21","date_gmt":"2026-07-12T20:19:21","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/07\/12\/cloudflare-cache-atualizacao-com-smart-tiered-cache-workers\/"},"modified":"2026-07-12T17:19:21","modified_gmt":"2026-07-12T20:19:21","slug":"cloudflare-cache-atualizacao-com-smart-tiered-cache-workers","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/07\/12\/cloudflare-cache-atualizacao-com-smart-tiered-cache-workers\/","title":{"rendered":"Cloudflare Cache: Atualiza\u00e7\u00e3o com Smart Tiered Cache, Workers Cache e Manuten\u00e7\u00e3o Global"},"content":{"rendered":"

\nEm um cen\u00e1rio onde cada milissegundo de lat\u00eancia pode significar a diferen\u00e7a entre uma convers\u00e3o e um abandono de carrinho, a Cloudflare Cache atualiza\u00e7\u00e3o<\/strong> de julho de 2026 chega como um divisor de \u00e1guas para profissionais de infraestrutura, desenvolvedores e arquitetos de sistemas. A Cloudflare \u2014 que hoje opera em mais de 300 cidades e 100 pa\u00edses pelo AS13335<\/strong>, processando aproximadamente uma em cada cinco requisi\u00e7\u00f5es HTTP da internet global \u2014 anunciou um conjunto de melhorias que afetam diretamente a forma como conte\u00fados est\u00e1ticos e din\u00e2micos s\u00e3o armazenados, distribu\u00eddos e invalidados em sua rede de edge computing. As novidades incluem o refinamento do Smart Tiered Cache<\/strong> para origens hospedadas em nuvens p\u00fablicas (AWS, GCP, Azure e Oracle Cloud), o lan\u00e7amento do Workers Cache<\/strong> \u2014 uma camada de cache regional diretamente acoplada aos entrypoints dos Workers \u2014 e uma s\u00e9rie de manuten\u00e7\u00f5es programadas em datacenters estrat\u00e9gicos como Toronto (YYZ), Barcelona (BCN) e Kansas City (MCI). Para o mercado brasileiro, onde a dist\u00e2ncia geogr\u00e1fica dos principais pontos de origem nos Estados Unidos e Europa imp\u00f5e lat\u00eancias naturalmente elevadas, essas atualiza\u00e7\u00f5es representam ganhos mensur\u00e1veis de performance.\n<\/p>\n

\nO contexto de edge computing em 2026 \u00e9 radicalmente diferente do que t\u00ednhamos h\u00e1 cinco anos. A proliferac\u00e3o de arquiteturas serverless, o crescimento dos bancos de dados distribu\u00eddos na borda \u2014 como o D1<\/strong> (SQLite) e o Vectorize<\/strong> (banco vetorial) \u2014 e a ado\u00e7\u00e3o massiva de frameworks como Next.js<\/strong>, Nuxt<\/strong> e Astro<\/strong> com SSR (Server-Side Rendering) criaram uma demanda sem precedentes por camadas de cache inteligentes que saibam diferenciar conte\u00fado est\u00e1tico de din\u00e2mico, respeitar headers de controle e, ao mesmo tempo, minimizar o tr\u00e1fego de volta \u00e0 origem. A Cloudflare respondeu a essa demanda com um ecossistema que vai muito al\u00e9m do CDN tradicional: Cache Reserve<\/strong> com R2<\/strong> eliminando custos de egress, Tiered Cache<\/strong> em m\u00faltiplas camadas reduzindo as idas ao servidor de origem, e agora o Workers Cache<\/strong> e o Smart Tiered Cache<\/strong> com dicas regionais de nuvem. Neste post, vamos dissecar cada uma dessas mudan\u00e7as t\u00e9cnicas e entender o impacto pr\u00e1tico para sua infraestrutura.\n<\/p>\n

\nSe voc\u00ea administra aplica\u00e7\u00f5es web com tr\u00e1fego significativo vindo do Brasil e da Am\u00e9rica Latina, sabe que a lat\u00eancia entre S\u00e3o Paulo e Virg\u00ednia (us-east-1 da AWS) gira em torno de 120\u2013140 ms em condi\u00e7\u00f5es ideais \u2014 e isso antes de considerar o tempo de processamento da origem. Cada requisi\u00e7\u00e3o que consegue ser resolvida diretamente no cache de um PoP (Point of Presence) em S\u00e3o Paulo, Rio de Janeiro ou Fortaleza representa uma economia brutal de tempo e recursos. As atualiza\u00e7\u00f5es que detalhamos a seguir foram desenhadas exatamente para aumentar essa taxa de cache hit na borda, reduzindo o tr\u00e1fego de ida e volta que penaliza usu\u00e1rios no Hemisf\u00e9rio Sul. Na JRT Technology Solutions<\/strong>, nossa equipe de especialistas em infraestrutura CDN j\u00e1 est\u00e1 implementando essas novas funcionalidades para clientes corporativos que operam e-commerces de alto volume, plataformas SaaS e portais de not\u00edcias com audi\u00eancia massiva.\n<\/p>\n

\nVamos mergulhar fundo em cada an\u00fancio: como o Smart Tiered Cache<\/strong> agora permite que voc\u00ea forne\u00e7a dicas regionais de nuvem para otimizar a sele\u00e7\u00e3o da camada superior, como o Workers Cache<\/strong> introduz uma camada de cache regionalmente tiered diretamente na frente dos seus entrypoints serverless, e como as manuten\u00e7\u00f5es programadas em datacenters como YYZ, BCN e MCI podem afetar \u2014 e como se preparar para \u2014 a re-rota de tr\u00e1fego. Tamb\u00e9m colocaremos a Cloudflare em perspectiva com Akamai<\/strong>, Fastly<\/strong> e AWS CloudFront<\/strong>, analisando em quais cen\u00e1rios cada provedor leva vantagem. Ao final, voc\u00ea ter\u00e1 um entendimento completo sobre como extrair o m\u00e1ximo dessas novas capacidades de cache e tomar decis\u00f5es informadas sobre sua arquitetura de distribui\u00e7\u00e3o de conte\u00fado.\n<\/p>\n

O que mudou no ecossistema de cache da Cloudflare em julho de 2026<\/h3>\n

\nA semana de 12 de julho de 2026 concentrou um volume not\u00e1vel de an\u00fancios e eventos programados no ecossistema Cloudflare. Para quem acompanha o Cloudflare Blog<\/strong> e os changelogs oficiais, tr\u00eas grandes frentes se destacam: o refinamento do Smart Tiered Cache<\/strong> para fornecer dicas regionais de nuvens p\u00fablicas, o lan\u00e7amento do Workers Cache<\/strong> como produto independente para desenvolvedores serverless, e uma s\u00e9rie de janelas de manuten\u00e7\u00e3o em datacenters de tr\u00eas continentes que impactam diretamente a topologia de cache e roteamento. H\u00e1 tamb\u00e9m melhorias correlatas \u2014 como o suporte a fun\u00e7\u00f5es de delay din\u00e2mico no Workflows<\/strong>, a migra\u00e7\u00e3o obrigat\u00f3ria dos Durable Objects<\/strong> para o backend SQLite, e a nova UX do DNS Firewall<\/strong> \u2014 que, embora n\u00e3o sejam estritamente sobre cache, afetam a forma como os dados trafegam e s\u00e3o armazenados temporariamente na rede da Cloudflare.\n<\/p>\n

\nO Smart Tiered Cache<\/strong> n\u00e3o \u00e9 novidade absoluta \u2014 ele existe como conceito desde que a Cloudflare introduziu o Tiered Cache<\/strong> com camadas superior e inferior. A arquitetura funciona assim: em vez de cada PoP ao redor do mundo consultar diretamente o servidor de origem quando h\u00e1 um cache miss, os PoPs de borda (camada inferior) consultam um PoP “upper tier” designado, que por sua vez consulta a origem. Isso reduz drasticamente o n\u00famero de requisi\u00e7\u00f5es que chegam ao seu servidor \u2014 especialmente relevante para origens que cobram por largura de banda de sa\u00edda, como AWS S3, ou para servidores com capacidade limitada de conex\u00f5es simult\u00e2neas. A atualiza\u00e7\u00e3o de julho de 2026 refina esse mecanismo: agora, se sua origem est\u00e1 hospedada na AWS<\/strong>, Google Cloud<\/strong>, Azure<\/strong> ou Oracle Cloud<\/strong>, voc\u00ea pode fornecer dicas de regi\u00e3o de nuvem para que o upper tier seja selecionado com precis\u00e3o geogr\u00e1fica, minimizando a lat\u00eancia entre o PoP de camada superior e o servidor de origem.\n<\/p>\n

\nJ\u00e1 o Workers Cache<\/strong> \u00e9 uma resposta direta a uma limita\u00e7\u00e3o arquitetural que incomodava desenvolvedores serverless: at\u00e9 ent\u00e3o, um Cloudflare Worker<\/strong> podia manipular e servir conte\u00fado cacheado usando a Cache API<\/strong> padr\u00e3o, mas esse cache estava atrelado ao CDN global e n\u00e3o oferecia controle granular de tiering na camada do Worker. Com o novo Workers Cache, cada Worker passa a ter sua pr\u00f3pria camada de cache regionalmente tiered, configur\u00e1vel via headers HTTP padr\u00e3o e infinitamente compon\u00edvel \u2014 voc\u00ea pode ter Workers aninhados, cada um com sua pol\u00edtica de cache, formando pipelines de processamento de conte\u00fado que minimizam round-trips \u00e0 origem sem abrir m\u00e3o de flexibilidade. Para aplica\u00e7\u00f5es que usam Next.js ISR<\/strong> (Incremental Static Regeneration), Remix<\/strong> ou SvelteKit<\/strong> com SSR, isso significa p\u00e1ginas din\u00e2micas servidas a partir do cache regional com lat\u00eancia de single-digit milissegundos.\n<\/p>\n

\nAs manuten\u00e7\u00f5es programadas \u2014 YYZ (Toronto)<\/strong> em 15 de julho, BCN (Barcelona)<\/strong> entre 14 e 15 de julho, e MCI (Kansas City)<\/strong> em 14 de julho \u2014 merecem aten\u00e7\u00e3o especial de administradores de infraestrutura. Durante essas janelas, o tr\u00e1fego ser\u00e1 re-roteado para datacenters adjacentes, o que pode causar um aumento pontual de lat\u00eancia e, mais criticamente, esvaziar temporariamente o cache local dos PoPs afetados. Se sua aplica\u00e7\u00e3o depende de cache quente em regi\u00f5es espec\u00edficas, essas janelas de manuten\u00e7\u00e3o exigem planejamento proativo. Felizmente, a Cloudflare agora permite assinar notifica\u00e7\u00f5es diretamente pelo dashboard para receber alertas via email, PagerDuty e webhooks \u2014 funcionalidade que recomendamos fortemente ativar para todos os clientes gerenciados pela JRT Technology Solutions<\/strong>.\n<\/p>\n

Cloudflare Cache atualiza\u00e7\u00e3o: Smart Tiered Cache com dicas regionais para nuvens p\u00fablicas<\/h3>\n

\nO an\u00fancio intitulado “Improving Smart Tiered Cache for Public Cloud Regions”<\/strong>, publicado no Cloudflare Blog, marca um avan\u00e7o significativo na arquitetura de cache em camadas. At\u00e9 junho de 2026, o algoritmo de sele\u00e7\u00e3o do upper tier para o Tiered Cache<\/strong> era baseado primariamente em topologia de rede e proximidade geogr\u00e1fica gen\u00e9rica \u2014 o que funcionava bem para origens f\u00edsicas em data centers conhecidos, mas frequentemente resultava em escolhas sub\u00f3timas para origens hospedadas em provedores de nuvem p\u00fablica. A raz\u00e3o \u00e9 sutil, mas poderosa: a AWS, por exemplo, opera dezenas de regi\u00f5es (de us-east-1<\/strong> na Virg\u00ednia a sa-east-1<\/strong> em S\u00e3o Paulo), e a proximidade geogr\u00e1fica bruta entre um PoP da Cloudflare e a regi\u00e3o de origem nem sempre corresponde \u00e0 menor lat\u00eancia de rede \u2014 roteamento BGP, peering e backbones internos dos provedores de nuvem introduzem vari\u00e1veis que um algoritmo puramente geogr\u00e1fico n\u00e3o captura.\n<\/p>\n

\nCom a atualiza\u00e7\u00e3o de julho de 2026, os clientes Enterprise<\/strong> da Cloudflare podem agora fornecer explicitamente a regi\u00e3o de nuvem onde sua origem est\u00e1 hospedada. O sistema usa essa dica para selecionar um upper tier que minimize a lat\u00eancia at\u00e9 aquela regi\u00e3o espec\u00edfica. Por exemplo, se sua origem est\u00e1 em AWS sa-east-1 (S\u00e3o Paulo)<\/strong>, o Smart Tiered Cache vai preferir um upper tier em um PoP da Cloudflare na Am\u00e9rica do Sul \u2014 como S\u00e3o Paulo, Rio de Janeiro ou Buenos Aires \u2014 em vez de simplesmente escolher um PoP “pr\u00f3ximo” do ponto de vista de coordenadas geogr\u00e1ficas. Essa otimiza\u00e7\u00e3o pode reduzir a lat\u00eancia entre o upper tier e a origem em 30% a 60%, dependendo da topologia, o que se traduz em cache misses resolvidos muito mais rapidamente e, consequentemente, em melhor experi\u00eancia para o usu\u00e1rio final.\n<\/p>\n\n\n\n\n\n\n\n\n\n
Provedor de Nuvem<\/th>\nRegi\u00e3o de Origem (Exemplo)<\/th>\nUpper Tier Sugerido (Smart)<\/th>\nRedu\u00e7\u00e3o Estimada de Lat\u00eancia<\/th>\n<\/tr>\n<\/thead>\n
AWS<\/td>\nsa-east-1 (S\u00e3o Paulo)<\/td>\nPoP GRU (S\u00e3o Paulo) ou GIG (Rio)<\/td>\n40\u201360% vs. upper tier gen\u00e9rico<\/td>\n<\/tr>\n
Google Cloud<\/td>\nsouthamerica-east1 (S\u00e3o Paulo)<\/td>\nPoP GRU (S\u00e3o Paulo)<\/td>\n35\u201350% vs. upper tier gen\u00e9rico<\/td>\n<\/tr>\n
Azure<\/td>\nBrazil South (S\u00e3o Paulo)<\/td>\nPoP GRU (S\u00e3o Paulo) ou CWB (Curitiba)<\/td>\n40\u201355% vs. upper tier gen\u00e9rico<\/td>\n<\/tr>\n
Oracle Cloud<\/td>\nBrazil East (S\u00e3o Paulo)<\/td>\nPoP GRU (S\u00e3o Paulo)<\/td>\n40\u201355% vs. upper tier gen\u00e9rico<\/td>\n<\/tr>\n
AWS<\/td>\nus-east-1 (Virg\u00ednia)<\/td>\nPoP IAD (Ashburn) ou EWR (Newark)<\/td>\n30\u201350% vs. upper tier gen\u00e9rico<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\nA mec\u00e2nica de configura\u00e7\u00e3o \u00e9 simples, mas requer acesso ao painel Enterprise<\/strong> ou \u00e0 API correspondente. No dashboard, ao definir as configura\u00e7\u00f5es de Tiered Cache<\/strong> para uma zona, surge uma nova op\u00e7\u00e3o chamada “Cloud Region Hints”<\/strong> onde voc\u00ea seleciona o provedor (AWS, GCP, Azure, OCI) e a regi\u00e3o espec\u00edfica. Internamente, a Cloudflare mapeia essa informa\u00e7\u00e3o para um subconjunto de PoPs de upper tier que t\u00eam menor lat\u00eancia comprovada para aquela regi\u00e3o de nuvem. Esse mapeamento \u00e9 atualizado dinamicamente com base em medi\u00e7\u00f5es cont\u00ednuas de lat\u00eancia e disponibilidade de rotas \u2014 n\u00e3o \u00e9 um mapeamento est\u00e1tico. Para administradores de infraestrutura que gerenciam m\u00faltiplas origens em diferentes provedores e regi\u00f5es, essa granularidade \u00e9 um salto de qualidade: voc\u00ea pode, por exemplo, ter origens em AWS us-east-1<\/strong> com upper tier otimizado na Am\u00e9rica do Norte e, simultaneamente, r\u00e9plicas de leitura em AWS sa-east-1<\/strong> com upper tier otimizado na Am\u00e9rica do Sul, cada uma recebendo tr\u00e1fego do Load Balancing<\/strong> da Cloudflare com geo steering.\n<\/p>\n

\nNa JRT Technology Solutions<\/strong>, configuramos o Smart Tiered Cache<\/strong> com dicas regionais para clientes que operam plataformas de e-commerce com origens multi-region. Um caso concreto: uma rede varejista brasileira com origens prim\u00e1rias em S\u00e3o Paulo (AWS sa-east-1) e r\u00e9plicas de conting\u00eancia em Virg\u00ednia (us-east-1). Antes da atualiza\u00e7\u00e3o, o upper tier para tr\u00e1fego vindo do Nordeste brasileiro frequentemente escolhia um PoP na Fl\u00f3rida para consultar a origem, resultando em lat\u00eancia acumulada de 200+ ms. Com as dicas regionais ativadas, o upper tier passou a ser consistentemente um PoP brasileiro, reduzindo a lat\u00eancia de cache miss em m\u00e9dia 45%. O resultado foi medido em aumento de taxa de convers\u00e3o e redu\u00e7\u00e3o de bounce rate nas p\u00e1ginas de produto \u2014 m\u00e9tricas que justificam sozinhas o investimento em uma configura\u00e7\u00e3o refinada de cache.\n<\/p>\n

Workers Cache: cache dedicado na frente dos seus Workers<\/h3>\n

\nO lan\u00e7amento do Workers Cache<\/strong>, anunciado no Cloudflare Blog sob o t\u00edtulo “Your Worker can now have its own cache in front of it”<\/strong>, resolve uma fric\u00e7\u00e3o arquitetural que todo desenvolvedor serverless que usa Workers em produ\u00e7\u00e3o j\u00e1 enfrentou. At\u00e9 esta atualiza\u00e7\u00e3o, a Cache API<\/strong> dispon\u00edvel dentro de um Worker operava sobre o cache global da CDN \u2014 o que significa que, embora voc\u00ea pudesse armazenar e recuperar objetos cacheados programaticamente, o cache n\u00e3o era “local” ao Worker, n\u00e3o respeitava boundaries de isolamento entre Workers diferentes na mesma zona, e n\u00e3o oferecia tiering regional espec\u00edfico para a camada serverless. O Workers Cache muda esse paradigma ao introduzir uma camada de cache que \u00e9 regionalmente tiered, que fica posicionada diretamente na frente dos entrypoints dos Workers, e que \u00e9 configur\u00e1vel via headers HTTP padr\u00e3o \u2014 Cache-Control<\/strong>, CDN-Cache-Control<\/strong>, Surrogate-Control<\/strong> e headers customizados da Cloudflare.\n<\/p>\n

\nA arquitetura do Workers Cache \u00e9 infinitamente compon\u00edvel \u2014 uma das caracter\u00edsticas mais celebradas pelos early adopters. Em termos pr\u00e1ticos, isso significa que voc\u00ea pode ter um Worker “A” que atua como entrypoint principal, aplica autentica\u00e7\u00e3o e rate limiting, e delega para um Worker “B” que busca dados de um banco D1<\/strong> e monta HTML din\u00e2mico. O Worker “B”, por sua vez, pode ter seu pr\u00f3prio Workers Cache configurado com TTL de 60 segundos para respostas HTML, enquanto o Worker “A” mant\u00e9m um cache separado para headers de autentica\u00e7\u00e3o com TTL de 5 minutos. O resultado \u00e9 uma pipeline de processamento onde cada est\u00e1gio pode ter sua pr\u00f3pria pol\u00edtica de cache, sem que um est\u00e1gio contamine o cache do outro. Para aplica\u00e7\u00f5es que implementam Incremental Static Regeneration<\/strong> (ISR) com frameworks como Next.js ou SvelteKit hospedados no Cloudflare Pages<\/strong>, essa granularidade \u00e9 revolucion\u00e1ria.\n<\/p>\n

\nTecnicamente, o Workers Cache opera com uma topologia de duas camadas similar ao Tiered Cache<\/strong> tradicional, mas otimizada para a natureza ef\u00eamera dos Workers. A camada inferior fica no pr\u00f3prio PoP onde o Worker est\u00e1 executando \u2014 lat\u00eancia de acesso inferior a 1 ms. A camada superior reside em PoPs regionais estrat\u00e9gicos, consolidando cache misses que n\u00e3o podem ser resolvidos localmente antes de acionar a execu\u00e7\u00e3o do Worker (que por sua vez pode consultar bancos de dados, APIs externas ou o R2<\/strong>). Essa arquitetura reduz significativamente o cold start percebido: um Worker que precisaria buscar dados de uma API externa em Ohio, com 150 ms de lat\u00eancia de rede, pode encontrar esses dados j\u00e1 cacheados na camada inferior do Workers Cache e responder em menos de 5 ms.\n<\/p>\n

\nUm detalhe importante para administradores de infraestrutura: o Workers Cache \u00e9 cobrado separadamente do cache CDN tradicional e seu pricing est\u00e1 atrelado ao n\u00famero de opera\u00e7\u00f5es de leitura\/escrita e ao volume de dados armazenados. Na pr\u00e1tica, os custos s\u00e3o ordens de magnitude menores do que o tr\u00e1fego de egress para a origem que ele evita \u2014 especialmente para origens em nuvens p\u00fablicas que cobram entre US$ 0,05 e US$ 0,09 por GB de sa\u00edda. Nossos especialistas em infraestrutura CDN na JRT Technology Solutions<\/strong> est\u00e3o recomendando aos clientes que adotem Workers Cache em conjunto com R2<\/strong> como camada de persist\u00eancia, eliminando completamente o custo de egress para a origem em cen\u00e1rios de conte\u00fado semi-est\u00e1tico que \u00e9 regenerado periodicamente.\n<\/p>\n

Cloudflare Cache atualiza\u00e7\u00e3o: impacto das manuten\u00e7\u00f5es programadas em YYZ, BCN e MCI<\/h3>\n

\nEntre 14 e 15 de julho de 2026, tr\u00eas datacenters estrat\u00e9gicos da Cloudflare passar\u00e3o por manuten\u00e7\u00e3o programada: MCI (Kansas City)<\/strong> em 14 de julho das 07:00 \u00e0s 12:00 UTC, BCN (Barcelona)<\/strong> de 14 de julho \u00e0s 13:00 UTC at\u00e9 15 de julho \u00e0s 21:00 UTC, e YYZ (Toronto)<\/strong> em 15 de julho das 06:00 \u00e0s 10:00 UTC. Embora manuten\u00e7\u00f5es programadas sejam rotina em qualquer infraestrutura de CDN global, o impacto sobre o cache local desses PoPs merece an\u00e1lise cuidadosa de administradores de sistemas. Durante a janela de manuten\u00e7\u00e3o, o tr\u00e1fego \u00e9 re-roteado para datacenters adjacentes \u2014 por exemplo, tr\u00e1fego de YYZ<\/strong> pode ser direcionado para ORD (Chicago)<\/strong> ou EWR (Newark)<\/strong>, enquanto BCN<\/strong> pode ter seu tr\u00e1fego absorvido por MAD (Madri)<\/strong> ou MRS (Marselha)<\/strong>. Para conex\u00f5es PNI<\/strong> (Private Network Interconnect) e CNI<\/strong> (Cloudflare Network Interconnect), as interfaces de rede nesses datacenters ficar\u00e3o temporariamente indispon\u00edveis, exigindo failover para outros pontos de presen\u00e7a.\n<\/p>\n

\nDo ponto de vista de cache, o efeito colateral mais relevante \u00e9 o esvaziamento do cache quente local. Cada PoP da Cloudflare mant\u00e9m seu pr\u00f3prio cache aut\u00f4nomo, populado com base nas requisi\u00e7\u00f5es dos usu\u00e1rios daquela regi\u00e3o geogr\u00e1fica. Quando o tr\u00e1fego \u00e9 desviado para um PoP adjacente, os objetos cacheados no PoP original n\u00e3o s\u00e3o automaticamente transferidos \u2014 o novo PoP precisar\u00e1 buscar o conte\u00fado fresco da camada superior (upper tier) ou, na pior das hip\u00f3teses, da origem. Para conte\u00fados com TTL longo e alta taxa de acesso, esse impacto \u00e9 m\u00ednimo: o cache do PoP adjacente pode j\u00e1 conter os objetos populares devido \u00e0 sobreposi\u00e7\u00e3o de audi\u00eancia ou, se n\u00e3o contiver, a primeira requisi\u00e7\u00e3o ir\u00e1 ao upper tier (que por sua vez frequentemente j\u00e1 tem o objeto cacheado). Para conte\u00fados com TTL curto, personalizados por regi\u00e3o ou com baixa popularidade, o impacto \u00e9 mais pronunciado \u2014 podendo gerar picos moment\u00e2neos de tr\u00e1fego \u00e0 origem.\n<\/p>\n

\nA Cloudflare recomenda explicitamente que clientes com PNI\/CNI<\/strong> nesses datacenters revisem suas configura\u00e7\u00f5es de failover antes da janela de manuten\u00e7\u00e3o. Para clientes gerenciados pela JRT Technology Solutions<\/strong>, nossa pr\u00e1tica padr\u00e3o \u00e9 revisar os dashboards de analytics com 48 horas de anteced\u00eancia para identificar quais zonas e quais endpoints espec\u00edficos dependem pesadamente de cache nos PoPs afetados, e ent\u00e3o pr\u00e9-aquecer o cache nos PoPs adjacentes que receber\u00e3o o tr\u00e1fego desviado. Essa t\u00e9cnica de cache warming preventivo, embora n\u00e3o documentada oficialmente, pode ser implementada via scripts que percorrem os URLs mais acessados e disparam requisi\u00e7\u00f5es X-Cache-Warm<\/strong> para os PoPs de destino \u2014 minimizando a probabilidade de cache misses durante a janela de manuten\u00e7\u00e3o.\n<\/p>\n

\nTamb\u00e9m vale destacar que a Cloudflare agora permite \u2014 dependendo do plano \u2014 assinar notifica\u00e7\u00f5es de status diretamente pelo dashboard, com entrega via email, PagerDuty e webhooks. Essa funcionalidade, documentada em developers.cloudflare.com\/notifications<\/strong>, \u00e9 particularmente \u00fatil para equipes de SRE e DevOps que precisam correlacionar eventos de manuten\u00e7\u00e3o programada com poss\u00edveis aumentos de lat\u00eancia ou de carga na origem. Se voc\u00ea ainda n\u00e3o configurou essas notifica\u00e7\u00f5es, este \u00e9 o momento: as manuten\u00e7\u00f5es de julho s\u00e3o um lembrete de que a infraestrutura de CDN, por mais resiliente que seja, n\u00e3o \u00e9 est\u00e1tica \u2014 e a observabilidade proativa \u00e9 o que separa um incidente de uma opera\u00e7\u00e3o tranquila.\n<\/p>\n

Como funciona o Tiered Cache e por que ele reduz lat\u00eancia e custos de origem<\/h3>\n

\nPara compreender plenamente o valor das atualiza\u00e7\u00f5es de julho de 2026, \u00e9 essencial revisitar a arquitetura do Tiered Cache<\/strong> da Cloudflare e os princ\u00edpios de engenharia que a sustentam. Em um CDN tradicional sem tiering \u2014 como o modelo b\u00e1sico do AWS CloudFront<\/strong> com origem \u00fanica ou mesmo configura\u00e7\u00f5es mais antigas do Fastly<\/strong> \u2014 cada PoP de borda ao redor do mundo atua de forma independente: quando um objeto n\u00e3o est\u00e1 em cache local (cache miss), o PoP consulta diretamente o servidor de origem. Se voc\u00ea tem 300 PoPs espalhados globalmente e um objeto popular com TTL de 60 segundos, teoricamente poderia haver at\u00e9 300 requisi\u00e7\u00f5es \u00e0 origem por minuto para o mesmo objeto \u2014 uma para cada PoP. Na pr\u00e1tica, o n\u00famero \u00e9 menor porque nem todos os PoPs recebem tr\u00e1fego para aquele objeto simultaneamente, mas o princ\u00edpio permanece: a fragmenta\u00e7\u00e3o geogr\u00e1fica do cache gera tr\u00e1fego redundante e custos desnecess\u00e1rios.\n<\/p>\n

    \n
  1. Camada inferior (Edge PoPs):<\/strong> cada PoP de borda consulta o upper tier designado em vez de consultar a origem quando h\u00e1 cache miss. O cache local na borda \u00e9 populado tanto por requisi\u00e7\u00f5es de usu\u00e1rios quanto por respostas do upper tier.<\/li>\n
  2. Camada superior (Upper Tier PoPs):<\/strong> um subconjunto menor de PoPs estrategicamente posicionados que consolidam as requisi\u00e7\u00f5es de m\u00faltiplos PoPs de borda. Se o upper tier tem o objeto em cache, ele responde imediatamente. Se n\u00e3o tem, apenas o upper tier consulta a origem \u2014 reduzindo drasticamente o n\u00famero de requisi\u00e7\u00f5es que chegam ao servidor de origem.<\/li>\n
  3. Cache Reserve (R2):<\/strong> uma camada adicional de armazenamento de longo prazo que funciona como “cache do cache”, utilizando o R2<\/strong> (object storage sem custo de egress). Objetos que expiram do cache tradicional mas ainda s\u00e3o acessados com frequ\u00eancia podem ser armazenados no Cache Reserve, evitando completamente a consulta \u00e0 origem por per\u00edodos extensos.<\/li>\n
  4. Smart Tiered Cache (2026):<\/strong> a evolu\u00e7\u00e3o que adiciona intelig\u00eancia baseada em dicas de regi\u00e3o<\/ol>\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":"

    Descubra as novidades do Cloudflare Cache: Smart Tiered Cache, Workers Cache e Manuten\u00e7\u00e3o Global. Melhore a performance do seu site agora!<\/p>\n","protected":false},"author":1,"featured_media":1489,"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":[2452,2455,2454,2431,2453,2430],"class_list":["post-1490","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cdn-cloudflare","tag-atualizacao-cloudflare-cache","tag-desempenho-de-site-cloudflare","tag-manutencao-cloudflare","tag-otimizacao-de-cache","tag-smart-tiered-cache","tag-workers-cache"],"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