Como a Vercel escala a Nexus G: edge network, ISR e o modelo de Fluid Compute

Já expliquei como o Supabase sustenta a camada de dado da Nexus G. A outra metade da equação de escala é onde a aplicação roda de fato, e a Vercel resolve isso com um modelo bem diferente de contratar mais servidor conforme o tráfego cresce. Entender as peças certas rede de borda, regeneração incremental e o modelo de computação que a Vercel chama de Fluid Compute é o que faz a plataforma aguentar crescimento sem virar gargalo nem custo desnecessário.

A primeira camada é a rede de borda, o conjunto de pontos de presença espalhados globalmente que a Vercel usa como CDN. Toda requisição chega primeiro no ponto de presença mais próximo do usuário, e se aquela resposta já está em cache ali, ela é servida na hora, sem nunca acionar a aplicação de verdade. Pra um perfil público da Nexus G, isso significa que um visitante em qualquer lugar do mundo recebe a página já pronta, vinda do ponto mais próximo geograficamente, em vez de esperar a requisição viajar até uma região específica de servidor.

A segunda camada é o Incremental Static Regeneration, o recurso do Next.js que a Vercel integra nativamente. Em vez de escolher entre página totalmente estática, que fica desatualizada, ou totalmente dinâmica, que gera carga a cada acesso, o ISR gera a página como estática e a revalida em background depois de um tempo configurado. Na prática, um perfil da Nexus G é servido instantaneamente do cache pra centenas de visitantes, e só quando o tempo de revalidação expira ou quando o dono atualiza o próprio perfil a página é regenerada, sem exigir rebuild do site inteiro nem consulta ao banco a cada acesso individual. É o meio-termo que aproveita a leitura pesada e escrita leve que já descrevi no artigo sobre o Supabase.

A terceira camada, e a mais nova das três, é o modelo de Fluid Compute. O modelo antigo de função serverless cobrava pelo tempo total de execução, incluindo o tempo em que a função ficava só esperando resposta de uma chamada externa exatamente o padrão de uma rota de API que consulta o Supabase e fica a maior parte do tempo aguardando o banco responder, não processando nada de fato. O Fluid Compute resolve isso com um roteador que decide em tempo real pra onde mandar cada requisição, reaproveitando instância já ativa antes de subir uma nova, e cobrando só pelo tempo de CPU realmente ativo, não pelo tempo total de espera. Duas estratégias reforçam esse modelo: uma instância de produção fica aquecida por padrão, evitando o atraso de cold start na maioria das requisições, e o sistema também analisa padrão de tráfego pra pré-aquecer instância extra antes de um pico esperado. Pra rotas de API da Nexus G que consultam perfil, conteúdo ou depoimento no Supabase rotas tipicamente dominadas por espera de rede, não por processamento pesado esse modelo reduz custo e latência ao mesmo tempo, sem exigir nenhuma mudança no código da aplicação.

A quarta peça, mais discreta mas relevante, é o Edge Middleware: código que roda antes da requisição chegar até a página, útil pra checagem de autenticação e redirecionamento. Na Nexus G, isso permite barrar acesso a rota de painel administrativo antes mesmo dela renderizar, sem carregar o peso de uma função completa só pra verificar se o usuário está autenticado.

O ponto que costuma escapar de quem só olha a Vercel como "onde fazer deploy do Next.js" é que essas quatro camadas resolvem problemas diferentes, e a escala real vem de combiná-las de acordo com o tipo de conteúdo: página pública de perfil se beneficia de rede de borda e ISR, porque é lida em massa e escrita raramente; rota autenticada de painel se beneficia de Fluid Compute, porque o gargalo ali é espera de banco, não processamento; e checagem de acesso se resolve no Edge Middleware, antes de qualquer coisa mais pesada ser acionada. Escalar não é aumentar recurso genericamente é reconhecer que cada tipo de rota tem um gargalo diferente, e resolver cada um com a ferramenta certa, exatamente como venho fazendo com o Supabase do outro lado da stack.