Cloudflare Radar Workers: inteligência da internet na edge
Em 2026, a internet não é apenas maior — é radicalmente mais distribuída, orientada a eventos e habitada por agentes autônomos que consomem APIs, publicam métricas e recalibram rotas em milissegundos. Nesse cenário, a capacidade de extrair inteligência do tecido da rede deixou de ser um luxo acadêmico e passou a compor o núcleo das decisões de infraestrutura, segurança e negócios. É exatamente aqui que Cloudflare Radar Workers se posiciona como um dos movimentos mais relevantes da engenharia de plataforma neste ano: a combinação da plataforma de inteligência de internet do Cloudflare Radar com o motor serverless dos Cloudflare Workers, rodando em mais de 300 data centers espalhados por todos os continentes.
O Cloudflare Radar nasceu como um painel público de indicadores de rede — adoção de IPv6, tráfego HTTP/3, ataques DDoS, rotas BGP — mas evoluiu para um verdadeiro centro de observabilidade global. A novidade de agosto de 2026 é que esse centro agora é programável, consultável por linguagem natural e alimentado por uma malha de computação na borda que elimina os gargalos tradicionais de latência e custo de egress encontrados nos hyperscalers. Com o lançamento do Radar Researcher, um assistente com IA generativa construído inteiramente sobre a Developer Platform da Cloudflare, e a exposição de endpoints de conectividade AS-level, o Radar se torna simultaneamente uma ferramenta de engenharia de rede e um caso de referência sobre o que significa construir software verdadeiramente edge‑native.
Para profissionais de TI no Brasil, o timing é crítico. Enquanto o mercado nacional ainda digere os impactos da LGPD, da explosão de APIs abertas no Open Finance e da consolidação de CDNs como primeira camada de defesa contra ataques de camada 7, ferramentas como o Radar Researcher e os Workers que o sustentam oferecem um modelo de como entregar latência de milissegundos, consultas analíticas sob demanda e roteamento inteligente sem depender de stacks centralizadas em us‑east‑1. Neste post, vamos abrir a arquitetura por trás dos Cloudflare Radar Workers, comparar com as alternativas do mercado, e mostrar como times de infraestrutura podem usar essa stack para monitorar, decidir e agir sobre dados reais da internet — inclusive no contexto brasileiro.
Ao longo das próximas seções, você vai entender por que o modelo de isolados V8 na edge representa uma quebra de paradigma frente ao serverless tradicional, como o Cloudflare Radar expõe grafos de conectividade entre sistemas autônomos e séries temporais de upstream providers via API, e de que forma a JRT Technology Solutions tem ajudado clientes corporativos a integrar Workers, R2, D1 e AI Gateway para construir painéis de inteligência de rede que respondem em português claro a perguntas complexas. Prepare seu terminal mental: vamos mergulhar fundo na interseção entre edge computing e inteligência de internet.
Radar Researcher e os novos recursos do Cloudflare Radar
A semana de 9 de agosto de 2026 marcou a liberação do Radar Researcher como beta público e a adição de widgets de conectividade AS‑level nas páginas de sistemas autônomos do Cloudflare Radar. O Researcher é um assistente de IA acessível diretamente do header de qualquer página do Radar — aceita perguntas por voz ou texto, gera gráficos interativos a partir da API do Radar e ainda permite que o usuário selecione um gráfico existente e peça “Explain with AI” para iniciar uma conversa contextualizada com os dados subjacentes. Tudo isso roda sobre Cloudflare Workers, D1 (SQLite distribuído), R2 (object storage sem taxas de egress) e AI Gateway, formando um pipeline de inferência que não toca em nenhum servidor tradicional.
Ao mesmo tempo, a seção Routing das páginas de AS — como a do AS13335 — agora exibe um grafo de conectividade AS‑level que agrega os caminhos BGP usados por uma rede para alcançar as Tier‑1 networks, lidos a partir de snapshots RIB do RouteViews, união através de múltiplos coletores. O grafo é orientado da esquerda para a direita, partindo do AS consultado até as Tier‑1, com nós rotulados por número de AS, país e organização, e um toggle para exibir caminhos completos ou apenas conexões diretas. Um seletor de versão IP alterna entre IPv4 e IPv6, já que as rotas para as Tier‑1 frequentemente divergem entre as duas famílias de endereços. O widget de Upstream providers complementa essa visão com um gráfico de área empilhada que mostra a evolução temporal da fatia de caminhos observados transportados por cada provedor upstream direto — até 10 séries individuais antes de agrupar em “Other”.
Ambos os widgets são retroalimentados por dois novos endpoints da API de BGP: /bgp/routes/paths/{asn}, que retorna os segmentos ordenados de AS paths com contagem de caminhos e peers, e /bgp/routes/upstreams/{asn}/timeseries, que entrega as séries temporais de share por upstream. Esses endpoints aceitam parâmetros como collector (para escopo de um coletor RouteViews específico), limit e ipVersion. Na prática, qualquer operador de rede pode agora consultar programaticamente a hierarquia de trânsito de um AS — inclusive o seu próprio — e detectar mudanças de rota, concentração de trânsito ou degradação de caminhos para o núcleo da internet.
Além do Researcher, o Radar agora suporta WebMCP, permitindo que agentes de IA baseados em navegador naveguem pelo Radar, busquem dados e utilizem ferramentas como URL scanning e domain lookup de forma autônoma. Isso abre um leque de cenários de automação: um agente que monitora a saúde de rotas para parceiros de peering pode consumir os endpoints de AS paths, cruzar com alertas de desempenho e disparar notificações sem intervenção humana. Toda essa inteligência é produzida pela mesma plataforma que qualquer desenvolvedor pode usar para construir suas próprias aplicações edge‑native.
Como Cloudflare Radar Workers combinam edge computing e inteligência de internet
O termo Cloudflare Radar Workers descreve a arquitetura em que Workers, R2, D1 e AI Gateway atuam como o motor computacional que ingere, processa e serve os dados do Radar. Diferente de uma stack analítica tradicional — onde coletores espalhados enviam telemetria para um data lake central que só então é consultado — aqui o processamento acontece nos próprios pontos de presença que originam ou observam os dados. Um Worker que responde a uma consulta do Radar Researcher, por exemplo, não precisa buscar todos os snapshots BGP em um bucket S3 em Virginia: ele consulta um banco D1 que replica incrementalmente apenas as janelas de rota relevantes para a pergunta, usa KV para cache de consultas frequentes, e emprega AI Gateway para rotear a inferência de linguagem natural para o modelo mais adequado — inclusive modelos rodando nas GPUs da própria Cloudflare via Workers AI.
Pense no seguinte pipeline: um usuário pergunta ao Researcher “Qual foi a latência média das rotas entre o ASN do meu provedor e as Tier‑1 nos últimos 7 dias, separada por IPv4 e IPv6?”. O Worker recebe essa string, utiliza AI Gateway para inferir a intenção e mapear para endpoints da API do Radar, dispara consultas paralelas para /bgp/routes/paths e para as séries de latência agregadas, junta os resultados, formata como JSON e devolve ao frontend que renderiza o gráfico interativo — tudo em menos de 200 ms. Se a mesma pergunta for feita novamente por outro usuário, KV retorna a resposta cacheada sem refazer o pipeline. Esse padrão de edge‑first data processing é o que torna os Cloudflare Radar Workers tão distintos.
A arquitetura se apoia em pilares que vale a pena detalhar. Primeiro, Workers são funções serverless que executam em V8 isolates — e não em containers ou VMs — com cold start abaixo de 1 ms e tempo de execução que pode chegar a 30 segundos para workloads CPU‑bound em modo unbound. Isso significa que mesmo consultas analíticas que exigem várias chamadas de API podem ser encadeadas sem o custo de inicialização que caracteriza funções Lambda tradicionais. Segundo, R2 armazena snapshots históricos de dados do Radar — tabelas de upstreams, grafos de AS paths, estatísticas de ataques — com zero custo de egress, removendo o atrito financeiro que mataria qualquer projeto de analytics público. Terceiro, D1 oferece SQLite-compatible queries em menos de 1 ms na borda, permitindo que o Researcher faça agregações e joins que seriam inviáveis em KV puro.
Quarto, AI Gateway unificado com Workers AI fornece um plano de controle único para observabilidade, cache, rate limiting e billing de todos os modelos de inferência — tanto os hospedados pela Cloudflare quanto provedores externos como OpenAI e Anthropic. O anúncio recente de unificação significa que um Worker pode chamar env.AI.run() com um único binding e rotear a requisição para @cf/zai-org/glm-5.2 ou para um modelo terceiro, com logs e métricas centralizados. Para o Radar Researcher, isso se traduz em flexibilidade para escolher o melhor modelo para cada tarefa — por exemplo, modelos leves para classificar a intenção da pergunta e modelos maiores para gerar sumarizações textuais — sem multiplicar a complexidade de código.
Por fim, Durable Objects e Queues entram em cena nos bastidores para manter estado consistente e filas de processamento assíncrono. Quando o Radar ingere uma nova snapshot RIB do RouteViews, um fluxo de eventos dispara Workers que atualizam as agregações em Durable Objects, que por sua vez populam as tabelas do D1 e invalidam caches KV. Essa coreografia, inteiramente orquestrada na borda, é a resposta da Cloudflare à pergunta “como construir um produto global de dados sem um data warehouse centralizado?”.
Cloudflare Radar Workers vs. ferramentas tradicionais de monitoramento de internet
Quem trabalha com engenharia de redes conhece ferramentas como ThousandEyes (Cisco), RIPE Atlas, BGPStream e CAIDA. Elas oferecem visibilidade de roteamento e latência, mas operam sob paradigmas distintos. O RIPE Atlas, por exemplo, depende de probes voluntários que realizam medições sob demanda — riquíssimo para pesquisa, mas com cobertura irregular e sem garantia de baixa latência para consultas programáticas. O ThousandEyes fornece telemetria corporativa de alto valor, porém atrelada a um modelo de licenciamento por unidade e a uma infraestrutura que não expõe APIs públicas para a comunidade. O Cloudflare Radar, alimentado por Cloudflare Radar Workers, inverte a equação: os dados vêm da própria rede que atende 20% do tráfego HTTP global, são processados na borda e expostos gratuitamente — com cotas generosas e endpoints RESTful documentados.
Em termos de granularidade, o novo grafo de conectividade AS‑level do Radar é inédito entre ferramentas gratuitas. Ele não apenas lista upstreams, mas mostra a topologia de trânsito até as Tier‑1, permitindo identificar se um AS depende de um único caminho para alcançar a Hurricane Electric, a NTT ou a Cogent. O widget de upstream providers temporal complementa essa visão estática com dinâmica: é possível ver, por exemplo, que um ISP brasileiro adicionou um novo trânsito com a Seaborn na semana passada, capturando 15% dos caminhos observados, enquanto reduziu a dependência de um provedor incumbente. Esses mesmos dados estão disponíveis via API, permitindo que engenheiros de plataforma construam dashboards internos ou alimentem pipelines de CI/CD que disparam alertas quando a diversidade de trânsito cai abaixo de um limiar.
A tabela abaixo consolida as diferenças arquiteturais e de modelo de consumo entre as principais ferramentas de inteligência de internet em 2026:
Outro diferencial importante é a integração entre dados de roteamento e dados de segurança. Enquanto ferramentas tradicionais segmentam BGP, DDoS e WAF em silos, o Radar correlaciona, por exemplo, picos de ataques DDoS com alterações de upstream providers observadas via BGP. Isso permite que um Security Operations Center identifique se um ataque volumétrico está forçando mudanças de trânsito — um insight que Cloudflare Radar Workers pode entregar em tempo real, consumindo os endpoints da API e produzindo alertas contextualizados.
Workers vs. Lambda@Edge vs. Vercel Edge: qual escolher e quando
A conversa sobre edge computing inevitavelmente leva à comparação entre as principais ofertas de serverless na borda. Embora o foco deste post seja Cloudflare Radar Workers, entender o posicionamento relativo ajuda a decidir onde construir cargas de trabalho que exigem latência ultrabaixa e processamento próximo ao usuário. As três plataformas — Cloudflare Workers, AWS Lambda@Edge e Vercel Edge Functions — compartilham a promessa de executar código na periferia da rede, mas divergem radicalmente em arquitetura de runtime, modelo de distribuição e custo.
Cloudflare Workers executam em V8 isolates, o mesmo motor JavaScript do Chrome, sem sobrecarga de container ou VM. O resultado é cold start consistentemente abaixo de 1 milissegundo e tempo de CPU wall-clock que, no plano Unbound, chega a 30 segundos — muito além dos 5 segundos típicos do Lambda@Edge. AWS Lambda@Edge, por outro lado, replica funções para regiões da CloudFront (cerca de 13 locais no lançamento inicial, embora em expansão), mas usa containers Firecracker que adicionam latência de inicialização e limitam a execução a 5 segundos para viewer events. Vercel Edge Functions também utilizam V8 isolates, oferecendo cold starts rápidos e integração profunda com frameworks frontend como Next.js, porém com um teto de execução de 30 segundos e um foco muito mais voltado para renderização e middleware do que para workloads de dados.
Do ponto de vista de distribuição geográfica, a Cloudflare opera mais de 300 cidades, enquanto a Vercel está na faixa de dezenas de regiões e a CloudFront, embora extensa, exige replicação explícita das funções. Isso significa que uma requisição vinda de Fortaleza ou Manaus, por exemplo, encontrará um Worker da Cloudflare a poucos milissegundos de latência, enquanto no Lambda@Edge pode ser servida por São Paulo ou, na pior hipótese, por uma região norte-americana. Para aplicações de inteligência de internet como as alimentadas pelo Radar, essa capilaridade não é luxo — é requisito funcional.
A tabela a seguir sintetiza os critérios essenciais de decisão:
