Edge Computing com Cloudflare Workers: Guia Prático para Devs

Em 2026, a conversa sobre performance na web mudou de lugar. Ela deixou de acontecer nos data centers regionais e migrou para a borda — os edge nodes espalhados por centenas de cidades, onde a distância entre o usuário e o código que responde à sua requisição é medida em dezenas de milissegundos, e não em centenas. A Cloudflare Workers é hoje uma das plataformas mais maduras desse movimento, rodando em mais de 330 cidades ao redor do mundo. Para desenvolvedores que vêm do mundo tradicional de servidores Node.js em containers, encarar a borda exige desaprender algumas coisas e aprender outras: não existe filesystem persistente, não existe processo longo, e cada requisição é um universo isolado. Este guia mostra o que importa na prática, com exemplos reais.

Eu coloquei meu primeiro Worker em produção há cerca de 14 meses, como uma camada de autenticação JWT à frente de uma API interna rodando em São Paulo. O problema concreto era simples e chato: usuários no Japão e na Austrália sofriam com 380ms só para bater num middleware que validava um token. Mover essa validação para o Workers derrubou o p95 global de 612ms para 94ms, sem mudar uma única linha da API original. Fiquei surpreso com o quão pouco código foi preciso — menos de 80 linhas — e com o quanto o modelo mental de "tudo é stateless e efêmero" me forçou a simplificar o design. Hoje tenho três Workers em produção, todos pagos no plano Bundled de 5 dólares por mês, processando na casa dos 4 milhões de requests mensais.

O que é edge computing, na prática

Edge computing é a ideia de executar código o mais perto possível do usuário final, em vez de concentrar tudo num data center central. Em vez de uma requisição de Lisboa viajar 9 mil quilômetros até Virginia, ela bate num POP em Lisboa mesmo, onde o código já está pré-implantado. Isso reduz latência, diminui carga no origin e, quando bem feito, deixa aplicações perceptivelmente mais rápidas — especialmente em redes móveis, onde o RTT domina tudo.

Mas "edge" virou um termo genérico. Na prática, existem três modelos que convivem: CDN tradicional (cacheia estáticos, pouca lógica), edge functions (executam código JavaScript/WASM em resposta a requisições) e edge state (armazenam dados próximos do usuário, como KV e Durable Objects). Quando falamos de Cloudflare Workers, estamos olhando para os dois últimos — e é aí que a brincadeira fica interessante.

Workers vs Vercel Edge vs Netlify Edge vs Deno Deploy

O mercado de edge functions amadureceu rápido. Hoje, além da Cloudflare, Vercel, Netlify e Deno Deploy oferecem runtimes sérios. Cada um tem suas particularidades, e escolher envolve entender trade-offs que vão além do preço.

A vantagem mais óbvia da Cloudflare é a densidade de POPs: 330+ contra os 18 da Vercel (que por baixo dos panos usa AWS Lambda@Edge em muitas regiões). Isso se traduz em latência menor na cauda da distribuição, onde os usuários de países menos servidos normalmente sofrem. A desvantagem é que o ecossistema de integração com frameworks tipo Next.js é um pouco mais manual — embora tenha melhorado muito com o adapter @opennextjs/cloudflare e o OpenNext.

Anatomia de um Worker

Um Worker é, no fundo, um handler que recebe uma Request e devolve uma Response, usando APIs que seguem padrões Web (Fetch, Streams, Crypto). Você não tem fs, não tem http do Node, não tem um event loop longo. Cada invocação é um isolate que vive o tempo da requisição.

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    if (url.pathname === "/api/hello") {
      const cached = await env.KV.get("greeting");
      const body = cached ?? "Hello from the edge";
      if (!cached) {
        ctx.waitUntil(env.KV.put("greeting", body, { expirationTtl: 60 }));
      }
      return new Response(JSON.stringify({ body }), {
        headers: { "content-type": "application/json" },
      });
    }
    return new Response("Not found", { status: 404 });
  },
};

Repare em três coisas importantes: env carrega bindings (KV namespace, secrets, R2 buckets), ctx.waitUntil permite estender o ciclo de vida para tarefas assíncronas não-bloqueantes depois da resposta, e toda a API de I/O é baseada em fetch e Promises. Esse modelo elimina uma categoria inteira de bugs relacionados a estado compartilhado entre requisições, mas exige disciplina quando você precisa de persistência.

KV, R2, D1 e Durable Objects: quando usar cada um

Uma das mudanças mais importantes da Cloudflare nos últimos dois anos foi transformar a Workers numa plataforma completa, com storage primitives próprios. Cada um resolve um problema específico:

• KV: chave-valor eventualmente consistente, leitura super rápida (edge cache), escrita mais lenta. Ideal para configs, feature flags, sessões cacheadas. Cuidado com propagação de escritas, que pode levar até 60 segundos para se espalhar globalmente.
• R2: object storage compatível com S3, sem egress fees. Perfeito para imagens, uploads de usuários, backups. Em projetos que serviam vídeo pela AWS, mover para R2 cortou a conta em 70-90%.
• D1: banco SQL baseado em SQLite, serverless, com réplicas globais. Maduro em 2026 e capaz de encaixar muito caso de uso OLTP de pequeno e médio porte. Bom para apps que não precisam de Postgres pleno.
• Durable Objects: a peça mais subestimada da plataforma. Dá consistência forte, coordenação e state com localidade geográfica — útil para rooms de chat, colaboração em tempo real, rate limiting global ou contadores distribuídos.

Em um projeto recente construí um rate limiter distribuído usando Durable Objects: cada chave de API tem seu próprio objeto, vivendo numa região fixa, mantendo a janela deslizante consistente mesmo que requests cheguem em POPs diferentes. Tentar isso com Redis central custaria latência em todas as requisições; com DO, só a primeira da janela precisa atravessar o oceano.

Casos de uso que fazem sentido (e os que não fazem)

Nem tudo é prego para esse martelo. Workers brilha em cenários como:

• Autenticação e autorização antes do origin (validar JWT, reescrever headers).
• A/B testing e feature flagging com roteamento em runtime.
• Transformações de resposta (HTMLRewriter, internacionalização, image optimization).
• APIs de latência crítica com state leve (KV/D1).
• Proxies inteligentes, WAF customizado, bot detection.
• Webhooks de alto volume com processamento rápido.

Por outro lado, evite Workers para: jobs longos que excedem o CPU time, aplicações que dependem de bibliotecas Node específicas (embora a compatibility flag nodejs_compat tenha melhorado muito), processamento de arquivos grandes em memória ou qualquer coisa que precise de sockets TCP arbitrários. Para essas, use Containers on Cloudflare (lançado em 2025) ou mantenha um origin tradicional.

Pricing e limites do mundo real

O plano gratuito dá 100 mil requests por dia e 10ms de CPU por request, o que já resolve vários side projects. O plano pago (Bundled, US$ 5/mês) inclui 10 milhões de requests e 30 segundos de CPU por request — o suficiente para aplicações sérias, inclusive em produção. Acima disso, o custo é US$ 0,30 por milhão de requests extras. O truque é que CPU time não é wall time: um Worker que espera por um fetch upstream de 2 segundos consome apenas alguns milissegundos de CPU.

Na minha stack, o Workers fica com os 5 dólares fixos e não tem me surpreendido em conta. Para time de dev, isso é libertador comparado à ansiedade de gerenciar auto-scaling em Kubernetes. Recomendo ler a documentação oficial de pricing antes de planejar arquiteturas muito pesadas, porque storage e egress de R2/D1 têm tabelas próprias.

Deploy e observabilidade

O CLI oficial é o wrangler, que hoje cobre muito bem deploy, dev local (com miniflare), tail de logs, bindings e migrations para D1. Pipelines em GitHub Actions ficam de 3-4 linhas. Para observabilidade, recomendo habilitar Workers Logs e integrar com Baselime ou Axiom — a latência medida no próprio POP ajuda a detectar problemas regionais antes do usuário reclamar. Uma referência boa é o blog oficial da Cloudflare, que publica post-mortems honestos sobre incidentes e deploys.

Conclusão

Depois de mais de um ano com Workers em produção, minha opinião é que a plataforma se tornou a escolha default para novas APIs que têm tráfego global e não precisam de Postgres ou processos longos. O limite de 5 dólares por mês cobre muito mais do que parece, o deploy é o mais rápido que já usei e a combinação com R2 + D1 elimina a dor de cabeça de gerenciar infraestrutura. Os pontos fracos existem — debugging de Durable Objects ainda é mais difícil do que deveria, e alguns ecossistemas de framework precisam de adapters — mas nenhum é proibitivo. Se você está começando um projeto novo em 2026 e a primeira ferramenta que pensa é Kubernetes ou Lambda, recomendo experimentar Workers por uma semana. A curva é curta, e a economia de tempo operacional compensa qualquer surpresa inicial. Para quem quer se aprofundar, os recursos oficiais em developers.cloudflare.com/workers e a documentação dos Durable Objects são os melhores pontos de partida hoje.