WebAssembly no edge: por que iniciar rápido e isolado importa

A premissa do serverless sempre foi sedutora: escreva uma função, não gerencie servidor, pague pelo uso real. O problema é que a implementação nunca foi tão limpa quanto o discurso. Containers precisam inicializar. Processos são reutilizados entre requests de clientes diferentes. E quanto mais global precisa ser o seu sistema, mais cara fica a latência de uma função acordando a frio do outro lado do planeta. WebAssembly no edge resolve exatamente esse conjunto de problemas — não por ser mais rápido em throughput bruto, mas por ter um modelo de execução fundamentalmente diferente.

O problema com cold starts

Quando uma função Lambda recebe sua primeira requisição depois de um período de inatividade, o runtime precisa inicializar o ambiente. Dependendo da linguagem e do tamanho do pacote, isso custa entre 100ms e 500ms. Container no Cloud Run ou Kubernetes? Pode ser de um a dez segundos até estar pronto para servir tráfego. Para APIs internas onde latência P99 não é questão crítica, dá para conviver. Para lógica que toca cada request de um usuário — roteamento geográfico, validação de token, personalização de header, testes A/B — aquele tempo vira problema visível.

O Cloudflare Workers e o Fastly Compute fizeram escolhas de arquitetura que eliminam esse problema de forma estrutural. No Workers, o código roda em isolates do V8, compartilhamentos leves dentro do mesmo processo. O isolate já existe; quando chega um request, é despachado em microssegundos. O cold start, na prática, aproxima-se de zero. No Fastly Compute, a abordagem é mais direta ainda: o módulo Wasm é compilado antecipadamente para código nativo da máquina hospedeira e carregado como unidade de execução pura. Sub-milissegundo do início ao processamento.

Deno Deploy segue linha parecida, com suporte a TypeScript, JavaScript e Wasm distribuído em mais de trinta localizações de borda. O resultado é o mesmo: o gap entre "request chegou" e "função começou a executar" colapsa para algo que não é mais mensurável em experiência de usuário.

Isolamento por request, não por processo

Existe um detalhe que raramente aparece nos tutoriais de serverless mas que importa muito em ambientes multi-tenant: o que acontece entre requests consecutivos dentro do mesmo processo?

Em funções Lambda e Cloud Run, o container ou processo é frequentemente reutilizado para ganhar eficiência. Isso é bom para performance, mas cria uma janela onde estado acidental pode vazar entre invocações. Variáveis globais modificadas por um request podem influenciar o próximo. Conexões abertas, caches em memória — tudo isso persiste no mesmo processo. Para aplicações estateless por design com equipes disciplinadas, não é problema. Mas é uma superfície de risco que existe.

O modelo Wasm no edge fecha essa superfície de outra forma. Cada módulo Wasm opera em sua própria memória linear: um array contíguo de bytes que é privado àquele módulo. Não existe heap compartilhado entre requests. Não existe forma de um request ler a memória de outro, mesmo que estejam rodando no mesmo hardware ao mesmo tempo. O isolamento não depende de processo separado; está no nível do modelo de execução da máquina virtual.

Para plataformas que rodam lógica de milhares de clientes no mesmo hardware, esse detalhe não é opcional. É a diferença entre um modelo de segurança que você pode raciocinar formalmente e um que depende de boas práticas de cada equipe.

Onde edge Wasm ganha de Lambda e Cloud Run

A vitória não é universal. Há um conjunto específico de casos onde a combinação de início instantâneo, distribuição global e isolamento por request cria diferença real de produto.

Lógica que precisa estar próxima do usuário geograficamente se beneficia mais. Roteamento por localização, respostas personalizadas por mercado, validação de autenticação antes de chegar ao servidor de origem — tudo isso tem latência diretamente impactada por onde o código roda. Uma função no edge opera numa presença de rede a dezenas de milissegundos do usuário, não numa região de nuvem a centenas.

Modificação de request e response também encaixa bem: injetar headers, reescrever URLs, aplicar cache customizado, fazer redirect baseado em A/B test. São operações de baixa CPU e alto impacto em experiência. Lógica de rate limiting e detecção de bots ganha igualmente — controlar tráfego antes de ele chegar à infraestrutura principal, customizado por tenant, executado globalmente.

Onde o modelo não se sustenta

O limite de CPU por request é estrito — cerca de cinquenta milissegundos na maioria das plataformas. Qualquer processamento mais longo está fora do modelo.

Cargas de trabalho com estado são o outro limite estrutural. Wasm no edge não tem acesso nativo a banco de dados, e qualquer persistência passa por chamada de rede à origem. Se a lógica do negócio é ler, transformar e escrever dados, a latência dessa chamada pode cancelar qualquer ganho do edge. Dependências pesadas também são um problema: um módulo Wasm de megabytes de bibliotecas perde a vantagem de inicialização rápida.

O trade é explícito: você ganha distribuição global e início instantâneo, e abre mão de processos de longa duração, acesso rico ao sistema operacional e workloads que precisam de mais CPU. Aceitar esse trade para os casos certos — e rejeitar para os errados — é a decisão de arquitetura que importa.

O que o líder técnico precisa avaliar

A pergunta produtiva não é "devemos usar edge Wasm?" mas "qual fração da lógica de borda da nossa plataforma ganha com esse modelo?" Quase toda plataforma tem lógica que toca cada request: autenticação, roteamento, feature flags, cache personalizado. Essa lógica é candidata natural.

A avaliação começa mapeando latência atual por região geográfica. Se há divergência grande entre P50 e P99 dependendo de onde o usuário está, edge compute entra na conversa. Se a base de usuários é geograficamente concentrada, o benefício reduz.