Edge computing: latência é decisão de arquitetura

Edge computing melhora a performance web quando a aplicação move decisões simples e frequentes para perto do usuário: cache, roteamento, autenticação leve, personalização controlada e proteção contra abuso. O ganho real não vem de trocar um servidor central por dezenas de pontos mágicos, mas de reduzir ida e volta de rede em partes críticas da experiência.

Por que a latência pesa tanto?

O navegador não sente arquitetura bonita. Ele sente tempo. Uma conexão entre São Paulo e Virgínia pode adicionar mais de 100 ms de latência ida e volta antes mesmo de a aplicação executar uma linha de regra de negócio. Em fibra óptica, a luz viaja perto de 200.000 km/s, algo em torno de 5 microssegundos por quilômetro em um sentido.

Por isso, performance web moderna precisa olhar além do tempo de renderização. Core Web Vitals dão uma régua útil: LCP bom fica até 2,5 segundos, INP até 200 ms e CLS abaixo de 0,1. Só que um LCP ruim pode nascer bem antes do React, Vue ou Drupal renderizarem qualquer coisa: DNS lento, cache mal configurado, HTML não cacheável, API distante ou autenticação que força múltiplas viagens até a origem.

O que deve rodar na borda?

A borda é boa para decisões pequenas, rápidas e com dependências limitadas. Ela é ruim para processos longos, transações complexas, consistência forte e regras que mudam a cada deploy do monolito. Essa separação evita um erro comum: transformar edge functions em um backend paralelo, com logs piores, testes mais frágeis e acoplamento escondido.

Bons casos de uso incluem:

• Cache de HTML e fragmentos públicos: páginas editoriais, landing pages, documentação, páginas de produto e resultados com baixa variação por usuário.
• Roteamento inteligente: enviar usuários para regiões, versões ou backends diferentes com base em país, idioma, cookie de experimento ou status de manutenção.
• Autenticação leve: validar assinatura de JWT, bloquear token expirado e encaminhar apenas requisições válidas para a origem.
• Personalização segura: variar conteúdo por segmento amplo, como país ou plano, sem consultar banco a cada request.
• Proteção e redução de carga: rate limit, bloqueio de padrões óbvios de scraping e normalização de headers antes do backend.

Um exemplo simples é separar cache por idioma e dispositivo sem explodir a cardinalidade. Em vez de variar por todos os cookies, a camada edge pode calcular uma chave pequena e previsível:

cacheKey = pathname + ':' + country + ':' + language + ':' + deviceType

if (method === 'GET' && isPublicPage(pathname)) {
  response = await cache.match(cacheKey)
  if (!response) {
    response = await fetch(originRequest)
    cache.put(cacheKey, response.clone())
  }
  return response
}

A ideia não é esse pseudocódigo ir direto para produção. A ideia é mostrar o princípio: cache útil depende de chave pequena, invalidação compreensível e regras que qualquer pessoa do time consiga debugar numa sexta-feira.

Quando a borda piora a arquitetura?

Edge computing piora a arquitetura quando vira atalho para problemas de domínio. Se uma regra exige transação bancária, escrita coordenada em banco relacional, fila confiável ou consistência imediata entre regiões, a borda provavelmente não é o lugar principal. Ela pode validar, enriquecer ou rejeitar cedo, mas a decisão de verdade continua em serviços desenhados para isso.

Também existe o custo de operação. Executar em múltiplas regiões muda como o time pensa sobre deploy, rollback, logs e métricas. Um erro que antes aparecia em um servidor agora pode aparecer só para usuários da França. Sem observabilidade por região, status de cache, tempo até a origem e taxa de erro por rota, edge vira uma caixa bonita e escura.

Alguns sinais de alerta são bem práticos:

• Funções edge chamando três ou quatro APIs internas antes de responder.
• Cache variando por cookie inteiro, criando milhares de versões quase iguais.
• Regras de negócio duplicadas entre backend central e edge.
• Deploy de borda sem teste automatizado para headers, redirects e fallback.
• Logs sem request ID compartilhado entre CDN, edge function e origem.

Outro ponto importante é banco de dados. Bancos distribuídos, réplicas de leitura e KV stores ajudam, mas cobram preço: latência de propagação, modelo de consistência, limite de tamanho ou custo por operação. Para muitas aplicações, um bom cache HTTP com stale-while-revalidate resolve mais que uma migração apressada para um banco global.

Como desenhar uma estratégia de edge sem exagero?

Comece medindo. Separe TTFB por região, taxa de cache hit, tempo de resposta da origem, tamanho do HTML, chamadas críticas de API e rotas com maior tráfego. Se 70% das visitas caem em 20 páginas públicas, cache e revalidação podem gerar mais impacto do que reescrever o backend.

Um desenho conservador costuma funcionar bem em quatro camadas. A primeira é CDN para assets estáticos com cache longo e nomes versionados. A segunda é cache de páginas públicas ou semipúblicas com invalidação por tag, webhook ou tempo curto. A terceira é edge logic para roteamento, segurança e pequenas variações. A quarta continua sendo a origem, responsável por regras complexas, escrita e integração com sistemas internos.

Na prática, um cabeçalho simples pode mudar o jogo:

Cache-Control: public, max-age=60, s-maxage=600, stale-while-revalidate=300

Nesse exemplo, o navegador pode manter a resposta por 60 segundos, enquanto caches compartilhados podem usar por 10 minutos e ainda servir conteúdo levemente antigo por 5 minutos enquanto revalidam. Para uma página editorial ou catálogo pouco sensível, isso reduz pressão na origem sem sacrificar atualização razoável.

O critério final é simples: coloque na borda o que reduz latência sem aumentar demais a complexidade. Uma boa estratégia de edge deixa o backend respirar, melhora Core Web Vitals e mantém o sistema explicável. Quando a equipe consegue responder “por que esta requisição foi para cá, com este cache e este fallback?”, a infraestrutura está trabalhando a favor do produto.

Perguntas frequentes

O que é edge computing na web?

É executar parte da lógica da aplicação em servidores próximos ao usuário, geralmente na camada de CDN ou pontos de presença distribuídos. O objetivo é reduzir latência, aliviar a origem e responder mais rápido a requisições frequentes.

Edge computing substitui backend tradicional?

Não. A borda complementa o backend, especialmente em cache, roteamento, segurança e personalização leve. Regras complexas, escrita consistente e integrações críticas normalmente continuam em serviços centrais.

Edge melhora Core Web Vitals?

Pode melhorar, principalmente TTFB e LCP, quando reduz viagens até a origem e entrega HTML ou dados críticos mais rápido. Mas INP e CLS ainda dependem de frontend bem implementado.

Quando não vale a pena usar edge?

Não vale quando a lógica exige transações fortes, muitas dependências internas ou debug detalhado que o time ainda não consegue observar. Nesses casos, otimizar cache, banco e APIs centrais pode trazer resultado com menos risco.