“Everything fails, all the time.” — Werner Vogels, CTO, Amazon Web Services
A cloud tradicional tem um problema de física.
Um usuário em São Paulo conectando a um servidor em us-east-1 experimenta 150-200ms de latência antes de receber o primeiro byte. Isso não é um problema de configuração. É a velocidade da luz operando em cabos de fibra óptica.
Mas latência não é o único problema. O segundo problema é mais silencioso e mais caro: egresso de dados.
Toda vez que um dado sai de uma região de cloud para o mundo externo, você paga. AWS cobra entre $0,08 e $0,09 por GB de egresso [1]. GCP e Azure têm tabelas similares. Em aplicações de alto volume, esse custo não é linha de item no orçamento. É o orçamento inteiro.
A combinação de Edge Computing com Zero Egresso resolve os dois problemas ao mesmo tempo. Não é uma otimização. É uma mudança de modelo.
O que é Edge Computing, de fato
Edge Computing não é “serverless mais perto do usuário”. Essa definição é preguiçosa e leva a decisões erradas.
Edge Computing é execução de lógica em pontos de presença (PoPs) distribuídos globalmente, tipicamente a 5-30ms do usuário final, em vez de 100-300ms de um datacenter centralizado.
Edge Runtime vs. Serverless Tradicional
| Propriedade | V8 Isolate (Edge) | Container (Serverless) |
|---|---|---|
| Cold Start | < 1ms | 100-1.000ms |
| Limite de CPU | 30-50ms | Minutos |
| Limite de Memória | 128MB | 512MB-10GB |
| Node.js APIs | Nenhuma | Completa |
| Deploy Global | 300+ PoPs | 1-4 regiões |
| Modelo de Custo | Por requisição | Por GB-segundo |
O runtime de edge expõe Web Standard APIs: fetch, Request, Response, Headers, Streams. Não expõe fs, path, ou módulos nativos. Qualquer função que usa apenas Web APIs é edge-compatível sem modificação. Qualquer função que depende de builtins do Node.js precisa ficar na origin.
Essa restrição não é um bug. É o contrato.
O edge é projetado para lógica leve e de alta frequência: autenticação, roteamento, personalização, geolocalização, validação de tokens. Não para processamento pesado, queries complexas de banco de dados, ou operações de I/O intensivo.
Quando o Edge faz sentido
Use edge quando:
- A lógica é invocada em toda requisição e bloqueia o rendering
- O workload precisa de latência abaixo de 50ms sem negociação
- A computação é stateless ou usa KV stores globalmente replicados
- O volume é alto o suficiente para que cold starts de container sejam um problema estrutural
Não use edge quando:
- A lógica depende de banco de dados relacional com consistência forte
- O processamento exige mais de 50ms de CPU
- O workload é esporádico e cold start de container é aceitável
Zero Egresso: o problema que ninguém menciona na reunião de arquitetura
Egresso de dados é o custo que não aparece no whiteboard de arquitetura. Aparece na fatura.
A premissa da cloud centralizada é que você processa dados em um datacenter e os envia para o mundo. Cada GB que sai desse datacenter tem um preço. Nas grandes clouds, esse preço varia entre $0,08 e $0,09 por GB para tráfego externo, com descontos progressivos em volumes massivos que a maioria das empresas nunca atinge.
O resultado prático: em aplicações com alto volume de dados, egresso pode representar 10-15% do total da fatura de cloud, segundo o Flexera State of the Cloud Report [2]. Em workloads de vídeo, imagens, ou telemetria de IoT, esse número sobe para 40-70%.
Por que Zero Egresso muda a equação
Zero Egresso não significa “dados não saem do sistema”. Significa que o dado é processado onde ele já está, eliminando a transferência entre regiões ou entre o datacenter e o usuário final.
Plataformas como o Cloudflare R2 foram projetadas explicitamente com esse modelo: armazenamento de objetos compatível com S3, sem cobranças de egresso. O dado sai do R2 para o worker de edge no mesmo PoP, sem cruzar fronteiras de rede que geram cobrança.
A lógica é simples:
- Cloud tradicional: dado armazenado em us-east-1 → processado em us-east-1 → enviado para o usuário em São Paulo. Você paga pelo egresso de us-east-1 para o Brasil.
- Edge + Zero Egresso: dado armazenado em R2 → processado no PoP de São Paulo → entregue ao usuário. Transferência interna, sem cobrança de egresso.
O impacto em escala
Considere uma aplicação com 10TB de dados servidos por mês para usuários globais:
| Modelo | Custo de Egresso (estimado) |
|---|---|
| AWS S3 + CloudFront | ~$850/mês |
| GCP Cloud Storage | ~$800/mês |
| Cloudflare R2 + Workers | $0/mês |
Estimativas baseadas em pricing público da AWS, GCP e Cloudflare (março 2026). Valores reais variam conforme volume e região.
A diferença não é marginal. É estrutural. E ela cresce linearmente com o volume.
Os padrões de arquitetura que funcionam
Edge + Zero Egresso não é uma decisão binária. É um espectro. Os padrões abaixo representam os pontos de entrada mais comuns, ordenados por complexidade de migração.
Padrão 1: Edge Middleware + Origin Centralizada
O padrão mais conservador e o mais fácil de adotar. A origin existente não muda. Você adiciona uma camada de edge na frente.
Como funciona: o edge intercepta toda requisição, executa verificações leves (validação de token JWT, leitura de feature flags, roteamento geográfico) e encaminha para a origin com headers enriquecidos. A origin processa sem repetir as verificações.
Ganho imediato: redução de TTFB de 60-80% para usuários geograficamente distribuídos.
Zero egresso nesse padrão: o dado ainda vem da origin, mas a lógica de decisão não gera tráfego adicional. O ganho de egresso é parcial.
Padrão 2: Edge + KV Store Global
O passo seguinte: mover dados de leitura frequente para um KV store globalmente replicado (Cloudflare KV, Vercel Edge Config).
O que vai para o KV: feature flags, configurações de usuário, segmentos de personalização, dados de sessão. Qualquer dado que é lido em toda requisição e raramente atualizado.
O trade-off crítico: KV stores são eventualmente consistentes. Escritas propagam em segundos para todos os PoPs. Se a lógica da sua aplicação depende de consistência forte no momento da leitura, esse padrão não serve. Se a lógica tolera dados com até 10 segundos de defasagem, o ganho de latência justifica o trade-off.
Padrão 3: Edge-Native com Zero Egresso Completo
O padrão mais avançado: toda a stack roda no edge, com armazenamento em plataformas sem egresso.
- Compute: Cloudflare Workers ou equivalente
- Armazenamento de objetos: R2 (zero egresso)
- Banco de dados: D1 (SQLite na edge) ou Durable Objects para estado
- Cache: KV global
Quando faz sentido: aplicações novas, sem legado de origin, com workloads que cabem nas restrições de CPU do edge (30-50ms). APIs públicas de alto volume são o caso de uso mais direto.
Quando não faz sentido: sistemas com lógica de negócio complexa, transações distribuídas, ou dependências de bibliotecas que requerem Node.js completo.
Qual padrão escolher
A maioria das empresas começa no Padrão 1 e evolui para o 2. O Padrão 3 é ponto de chegada, não de partida.
O que não migrar para o edge
Edge Computing tem uma lista de casos de uso ideais. Mas a lista do que não funciona é igualmente importante e raramente documentada.
Limites de CPU são absolutos. No Cloudflare Workers, o limite padrão é 50ms de CPU por requisição. Não é um aviso. É um hard kill. Qualquer lógica que ultrapasse esse limite precisa ficar na origin.
Consistência eventual não é negociável. KV stores de edge são projetados para leitura de alta velocidade, não para escrita consistente. Durable Objects resolvem parte disso para estado local, mas com limitações de escalabilidade horizontal.
Debugging é mais difícil. Observabilidade em ambientes de edge é um problema em aberto. Logs distribuídos em 300+ PoPs com latência mínima de coleta exigem ferramentas específicas.
A regra prática: se a lógica é stateless, leve, e invocada em alta frequência, o edge é o lugar certo. Se qualquer um desses três critérios falhar, reconsidere.
A decisão de arquitetura
Edge Computing com Zero Egresso não é uma tendência. É uma resposta direta a dois problemas estruturais da cloud centralizada: latência determinada por física e custo de egresso que cresce com a escala.
A adoção não precisa ser total para gerar valor. O Padrão 1 (Edge Middleware) pode ser implementado em dias, sem tocar na origin, e já entrega redução de TTFB de 60-80% para usuários distribuídos.
A pergunta que todo engineering leader deveria fazer antes da próxima decisão de infra:
Qual parte da minha lógica é stateless, leve, e executada em toda requisição? Essa parte não deveria estar em us-east-1. Ela deveria estar a 20ms do usuário, sem custo de transferência.
Se a resposta for “a maioria da lógica de autenticação e roteamento”, você já tem o caso de uso para começar. O resto é sequenciamento.
Fontes
[1] Amazon Web Services, “Data Transfer Pricing,” aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer.
[2] Flexera, “State of the Cloud Report,” 2024. Disponível em: flexera.com/blog/cloud/cloud-computing-trends/.