Edge computing: rodando código na borda com CDN workers
A velocidade da luz é o teto que ninguém consegue furar. Um usuário em Tóquio que faz uma requisição a um servidor na Virginia paga o custo físico de os dados atravessarem o planeta e voltarem, e nenhuma otimização de código conserta esse tempo de viagem. Por décadas, a resposta foi aproximar apenas o conteúdo estático do usuário, com CDNs cacheando imagens e arquivos perto dele. A novidade dos últimos anos é mais radical: aproximar também o código, executando lógica na borda da rede, a poucos milissegundos de qualquer pessoa no mundo. Isso é edge computing.
Este guia trata de rodar código na borda com CDN workers. O que são, por que reduzem drasticamente a latência, quais os limites reais do ambiente de execução e em que casos brilham. O foco é a computação na borda, um território distinto do serverless tradicional, que executa funções em regiões centralizadas.
O que é edge computing
Uma CDN (Content Delivery Network) já mantém centenas de pontos de presença espalhados pelo mundo, os nós de borda, cada um perto fisicamente de um grupo de usuários. Tradicionalmente, esses nós só serviam cache de conteúdo estático. O edge computing transforma esses mesmos nós em pequenos ambientes de execução, capazes de rodar código ali, junto do usuário.
Os CDN workers (ou edge functions) são funções que rodam nesses nós de borda em vez de em um servidor central. Quando a requisição chega, ela não precisa viajar até um data center distante para que a lógica seja executada; o código roda no nó mais próximo, responde na hora e, quando necessário, só então fala com a origem. O ganho é geográfico: a computação acontece a milissegundos do usuário, não a um oceano de distância.
Edge não é serverless tradicional
A confusão mais comum é tratar edge como um sabor de serverless. Ambos executam código sob demanda sem você gerenciar servidores, mas há duas diferenças que mudam tudo.
A primeira é onde o código roda. O serverless tradicional (FaaS) executa em regiões centralizadas: você escolhe uma região, e a função roda lá, longe da maioria dos usuários. O edge executa em centenas de locais simultâneos, sempre no mais perto de quem chamou.
A segunda é o ambiente de execução. Para conseguir rodar em centenas de lugares e iniciar instantaneamente, o runtime de edge é leve e restrito, muitas vezes baseado em padrões web enxutos, com um cold start desprezível. O serverless tradicional oferece um ambiente mais completo, com mais memória, mais tempo e acesso a mais recursos, ao custo de latência geográfica e de cold starts maiores.
| Característica | Serverless tradicional (FaaS) | Edge (CDN workers) |
|---|---|---|
| Onde executa | Região centralizada | Centenas de nós de borda |
| Latência geográfica | Alta para usuários distantes | Mínima, perto de todos |
| Cold start | De dezenas de ms a segundos | Praticamente nulo |
| Ambiente de execução | Completo (mais memória e tempo) | Leve e restrito |
| Melhor para | Lógica pesada, tarefas de fundo | Lógica leve no caminho da requisição |
Onde o edge brilha
O edge não substitui o backend; ele intercepta a requisição no caminho e faz, ali mesmo, o que ganha em estar perto do usuário. Os casos que mais se beneficiam:
- Personalização e roteamento inteligente. Redirecionar o usuário para a versão certa do site conforme país, idioma ou dispositivo, sem uma ida ao servidor central. A decisão acontece na borda, instantânea.
- Testes A/B na borda. Dividir usuários entre variantes de uma página direto no nó de borda, servindo a versão certa sem latência extra nem cintilação na tela.
- Autenticação e autorização na borda. Validar um token e barrar requisições inválidas antes que elas cheguem à origem, aliviando o backend e cortando tráfego malicioso perto da fonte.
- Reescrita e manipulação de requisições. Adicionar cabeçalhos, reescrever URLs, montar respostas simples, tudo sem tocar o servidor central.
- Cache dinâmico e inteligente. Decidir na borda o que servir do cache e o que buscar na origem, com lógica mais rica que um TTL fixo.
O fio condutor: lógica leve, no caminho da requisição, que ganha muito em rodar perto do usuário. Sempre que a decisão pode ser tomada na borda em vez de esperar uma viagem ao data center, o edge entrega latência muito menor.
Os limites do runtime de borda
A leveza que torna o edge rápido é também sua maior restrição. Ignorar esses limites é a origem da maioria das frustrações com a tecnologia:
- Tempo de execução curto. Funções de borda têm um teto de tempo baixo por invocação. Elas são feitas para responder rápido, não para processar por segundos.
- Recursos enxutos. Menos memória e um ambiente restrito, sem muitas das bibliotecas e APIs que você usaria em um servidor tradicional.
- Acesso limitado a serviços. Falar com um banco de dados central da borda pode anular o ganho de latência, porque a chamada ao banco distante volta a atravessar o mundo. O edge trabalha melhor com dados também distribuídos ou com cache na própria borda.
A regra é clara: o edge é para trabalho leve e rápido no caminho da requisição, não para lógica pesada nem processos longos. Empurrar para a borda algo que ela não foi feita para fazer resulta em timeouts e complexidade sem o benefício esperado.
A armadilha do estado
Aqui está o cuidado mais sutil do edge computing. Como o código roda em centenas de locais independentes ao redor do mundo, não existe um estado local compartilhado entre eles. Uma variável definida no nó de Tóquio não existe no nó de Frankfurt. Cada invocação, em cada nó, é isolada.
Isso significa que edge functions precisam ser essencialmente stateless, ou apoiar-se em armazenamentos projetados para a borda, que replicam os dados globalmente e são consistentes de forma eventual. Tentar manter estado na memória de um nó de borda é um bug esperando para acontecer: funciona nos seus testes, falha em produção quando o usuário cai em outro nó. Todo estado precisa morar em uma camada feita para ser distribuída, e o desenvolvedor precisa aceitar a consistência eventual que vem junto.
Como decidir usar o edge
Um roteiro pragmático para saber quando levar código para a borda:
- A lógica é leve e está no caminho da requisição? Roteamento, personalização, autenticação simples, testes A/B: candidatos perfeitos para o edge.
- A decisão depende de dados centrais e pesados? Talvez o edge não ajude, porque a ida ao banco distante devolve a latência que você tentou eliminar.
- O processamento é longo ou pesado? Isso é trabalho de serverless tradicional ou de um backend, não da borda.
- O código pode ser verdadeiramente stateless? Se depende de estado local na memória, ele não está pronto para a borda.
A arquitetura mais madura combina as camadas: o edge cuida do que ganha em proximidade, o backend cuida da lógica de negócio pesada e dos dados centrais, e cada requisição resolve o máximo possível o mais cedo possível no caminho.
A borda como camada de latência
Edge computing é, na essência, uma resposta de engenharia ao limite físico da distância. Ao levar lógica leve para centenas de pontos perto dos usuários, ele corta a latência que nenhuma otimização de código central conseguiria, e alivia o backend ao resolver decisões antes que elas cheguem lá. O segredo está em respeitar a natureza da borda: código leve, rápido e sem estado local, no caminho da requisição. Usado assim, o edge é uma das alavancas mais poderosas de performance global de um SaaS. Forçado além do seu propósito, vira uma fonte de timeouts e bugs de estado difíceis de diagnosticar.
Seus usuários distantes sofrem com latência que o servidor central não resolve? Na ConstructorTI, desenhamos arquiteturas que usam edge computing no ponto certo, com roteamento, personalização e autenticação na borda, e mantêm a lógica pesada onde ela deve ficar. Se a experiência do seu produto muda conforme a região do usuário, fale com a nossa engenharia e receba um diagnóstico da sua estratégia de borda.