Quando usar microsserviços em 2026: escalar, por si só, já não é o motivo

O aplicativo da Robinhood apagou na abertura do mercado em 2 de março de 2020 e continuou apagado até o fechamento. Naquele dia o Dow subiu 1.294 pontos, um recorde à época, e o S&P 500 somou US$ 1,1 trilhão. Todo cliente da Robinhood, 12,5 milhões de contas segundo a FINRA, só pôde assistir. A lição que a maioria dos engenheiros tirou de dias assim foi microsserviços: separar o sistema para que a parte quente possa escalar sozinha.

Em 2026 essa lição já não se sustenta sozinha: uma plataforma serverless já escala cada função conforme o tráfego dela. Quando usar microsserviços agora se resume a outra pergunta: o que um split compra, e consigo mostrar a evidência antes de construí-lo?

Esta é a primeira parte de uma série em que construo um sistema distribuído real, o Bullpen, e faço cada split merecer seu lugar com um teste, uma medição ou uma fatura. Ela registra minha visão em setembro de 2026. As plataformas por baixo mudam todo mês, e partes deste texto vão envelhecer. Estou começando no mês em que Building Resilient Distributed Systems, de Sam Newman, chegou ao early release; o tema do livro, resiliência, é o que o segundo motivo abaixo pede que o Bullpen prove.

Por que escalar deixou de bastar para dividir

O relato da própria Robinhood sobre aquela manhã merece leitura atenta. Na atualização publicada no dia seguinte, os fundadores escreveram que volume recorde, mercados voláteis e um recorde de cadastros pressionaram a infraestrutura. A pressão disparou um thundering herd (estouro de manada), e a manada derrubou o sistema de DNS deles. O acordo de 2021 com a FINRA, uma multa de US$ 57 milhões mais cerca de US$ 12,6 milhões em ressarcimentos, aponta aquela indisponibilidade como a mais grave do período.

Minha leitura é que isso não foi a falha de escala que o discurso de microsserviços tinha em mente. Uma dependência compartilhada por todos os caminhos cedeu sob uma multidão, e tudo que estava atrás dela caiu junto. Mais serviços chamando o mesmo DNS teriam falhado da mesma forma. Uma manada é o que um contrato de chamador quebrado parece em escala máxima, algo sobre o qual escrevi em Backpressure é um contrato que todo chamador precisa honrar.

Software Architecture: The Hard Parts dá nome à unidade que compartilha destino: o quantum de arquitetura, uma unidade implantável de forma independente e com alta coesão funcional, mantida junta por dependências estáticas e chamadas síncronas. Pela minha leitura, serviços que esperam todos por uma mesma dependência se comportam como um único quantum em tempo de execução, não importa quantos repositórios existam.

A metade do argumento antigo que falava de escala também se moveu. A Vercel habilitou o Fluid compute por padrão em novos projetos desde abril de 2025, e uma instância de função pode atender mais de uma requisição ao mesmo tempo. A Vercel também agrupa rotas do Next.js no menor número possível de funções, e cada função ganha instâncias conforme seu tráfego cresce.

Uma rota que precisa de limites diferentes ganha seu próprio bundle por meio de uma entrada functions no vercel.json, ainda dentro de um único implantável. Esse é o split de "escalar a parte quente sozinha", feito como configuração e cobrado por uso. Argumentei nas minhas notas sobre backends que viraram software que dorme que o modelo de cobrança é o indício. O Bullpen é onde descubro se isso se sustenta sob uma carga real.

Bullpen, uma liga de paper trading sobre dados de mercado ao vivo

O Bullpen é uma liga em que jogadores negociam dinheiro fictício com ações e criptomoedas reais dos EUA a preços ao vivo, e um ranking os classifica conforme o mercado se move. Ele roda em planos gratuitos, e as APIs por baixo falham como sistemas de produção falham: execuções parciais, limites de taxa, mensagens perdidas.

Os preços de ações do Bullpen vêm da Alpha Vantage, a partir da Parte 3, e os de cripto, da CoinGecko. Todo plano gratuito de dados de mercado raciona chamadas, e essa cota é um limite que o sistema inteiro compartilha. O plano gratuito de dados de mercado da Alpaca é um exemplo típico: preços em tempo real apenas da bolsa IEX, no máximo 30 símbolos transmitidos e 200 chamadas de API por minuto. O paper trading da Alpaca também serve de régua para o realismo das ordens: ele executa ordens parcialmente, com tamanho aleatório, em 10% dos casos. Para cripto, minha primeira escolha foi o ticker público da Coinbase, que não exige chave. Os termos de dados de mercado da Coinbase proíbem exibir esses preços a qualquer pessoa fora da minha própria organização, então foram os termos, e não a API, que decidiram o provedor. O plano Demo gratuito da CoinGecko permite exibição pública desde que cada preço traga o crédito "Powered by CoinGecko".

A Parte 1 entrega a menor versão funcional: um app de landing, um app de trading com um símbolo ao vivo (BTC-USD da CoinGecko, atualizado a cada 5 minutos) e seus registros de decisão. Os dois apps vivem em um único monorepo Turborepo. Essa foi minha escolha para este projeto, e a Parte 2 a defende. Os dois apps não são um split no sentido que interessa a este post: eles compartilham pacotes, não guardam dados e nunca chamam um ao outro. Os splits que eu preciso justificar são os que colocam uma chamada de rede entre duas partes de uma mesma ordem.

Uma ordem, quatro necessidades, dois limites compartilhados

O argumento a favor de dividir aparece quando sigo uma única compra pelo sistema.

• O feed de preços precisa estar fresco, e consome de um único orçamento upstream que todas as partes do Bullpen compartilham.
• A ordem precisa reservar poder de compra antes de executar. Ela pode ser executada em parte e pode correr contra um cancelamento.
• O ledger precisa manter todos os saldos corretos. O poder de compra nunca pode ficar negativo, mesmo quando uma execução chega atrasada.
• O ranking precisa responder a todos os jogadores ao mesmo tempo, com o pico às 9h30, e tolera preços com alguns segundos de atraso.

Essas são quatro características de arquitetura diferentes no sentido de Ford e Richards: frescor, correção sob corridas, consistência estrita e fan-out de leitura. Dentro de um único implantável elas compartilham tudo: as mesmas instâncias de função, as mesmas conexões de banco, o mesmo orçamento de dados de mercado. O diagrama abaixo segue a compra da esquerda para a direita; observe os dois limites compartilhados embaixo, porque é ali que as necessidades colidem.

Nenhum dos limites aperta com um jogador só. Os dois apertam na abertura, quando todos os jogadores chegam no mesmo minuto.

O monólito que sustentaria uma liga de sala de aula

Para uma turma de 30 alunos, um app Next.js e um banco Postgres sustentariam o Bullpen sem dificuldade. O tráfego é pequeno, os dados de mercado cabem no orçamento e ninguém percebe um atraso de dois segundos. Para uma sala de aula, eu construiria essa versão e pararia por aí.

Ela quebra em três pontos assim que a liga cresce para além de uma sala, e os planos gratuitos colocam um número em cada um:

As fontes são os limites de duração de função da Vercel, a página de planos da Alpaca citada acima e a documentação de connection pooling da Neon, que lista 104 conexões para o menor compute, com 7 reservadas. O pooler da Neon aceita até 10.000 conexões de cliente, mas ainda as afunila para esse pool pequeno.

Cada linha aponta para uma fronteira. O stream quer algo que sobreviva a uma função. O orçamento de dados de mercado quer exatamente um dono que distribua os preços para todos os demais. O pool de conexões quer as escritas do ledger protegidas das leituras do ranking. Adicionar capacidade não resolve nenhum deles; cada correção impede que partes com necessidades diferentes compartilhem um mesmo destino.

A teoria da residualidade, de Barry O'Reilly, começa listando os estressores que poderiam atingir um sistema e pergunta o que sobra dele depois de cada um. Quatro são visíveis já no primeiro dia:

• O feed cai.
• Uma lacuna de sequência descarta uma mensagem de execução.
• O banco está frio às 9h30, porque o plano gratuito da Neon o escala para zero após 5 minutos ociosos e eu não posso desligar isso.
• O orçamento de dados de mercado acaba no meio da sessão.

Para cada um deles, o que me importa é o que o jogador vê: preços defasados rotulados como defasados, ordens pausadas em vez de perdidas, e nenhum saldo errado. O que sobra depois de cada estressor é a evidência que o segundo motivo abaixo exige.

Quando usar microsserviços: os cinco motivos que um split tem de merecer

Sam Newman foi direto em Monolith to Microservices: microsserviços não são o objetivo. Um split vale a pena quando a arquitetura atual não consegue alcançar um objetivo que eu consiga nomear. Escrevi os objetivos do Bullpen antes de construir qualquer coisa, no ADR-0002 do repositório do Bullpen. Todo split futuro precisa citar um de cinco motivos e trazer um teste, uma medição ou uma fatura como evidência:

1. Contenção de dados. Caminhos de escrita que não deveriam compartilhar um lock ou um banco. No Bullpen, reservar poder de compra e liquidar execuções versus leituras do ranking. A Parte 3 traz a evidência.
2. Isolamento de falhas. A indisponibilidade de uma parte não pode derrubar outra. No Bullpen, um feed de preços morto não pode impedir a entrada de ordens. O teste da manhã ruim na Parte 5 é a evidência, e isolamento tem um preço, sobre o qual escrevi em Arquitetura Baseada em Células Não É de Graça.
3. Mudança independente. Uma cadência de release que de fato difere. Espero que este seja o motivo mais fraco no Bullpen, porque uma pessoa só entrega tudo. A Parte 6 conta os deploys. O Bullpen também não consegue testar o motivo que mais pesa em muitas organizações: times que precisam ser donos da sua parte e entregá-la sem esperar uns pelos outros. Sou o único engenheiro, então a autonomia de times fica fora deste experimento; a Parte 6 esboça onde ficariam as fronteiras entre times se o Bullpen os tivesse.
4. Adequação de runtime. Uma carga de trabalho que o runtime padrão atende mal. No Bullpen, um stream que sobrevive a uma função de 300 segundos. Esse é o motivo por trás do serviço de ingestão em Rust mais adiante na série, e ele ainda precisa ser demonstrado, não presumido.
5. Um orçamento compartilhado. O ADR-0002 enquadra isso como custo dividido entre times. Com uma pessoa só no projeto, vira um limite do qual toda instância consome e que apenas um dono consegue administrar. No Bullpen, esse é o orçamento de chamadas de dados de mercado, como as 200 chamadas por minuto citadas acima.

Cada motivo justifica uma fronteira, não uma chamada de rede. Um módulo, uma função separada, um worker atrás de uma fila e um serviço separado são todos fronteiras, e escolho a mais barata que atende ao motivo. Só uma fronteira que precisa do próprio deploy, dos próprios dados e do próprio domínio de falha merece virar um microsserviço. Adequação de runtime quase sempre precisa, e mudança independente precisa por definição. Um orçamento compartilhado quase nunca precisa: um módulo dono do limitador basta.

Escalar, por si só, está fora dessa lista de propósito. Escalar ainda divide um sistema quando uma carga precisa de outro runtime, como um stream que sobrevive a uma função, e aí conta como adequação de runtime. Se eu não conseguir nomear um dos cinco, o split não acontece. Se a evidência nunca aparecer, o split é revertido.

Mais uma tentação a resistir: a Neon dá a cada projeto 0,5 GB próprios e 100 horas de compute por mês, então um banco por serviço multiplica minha cota gratuita em vez da minha fatura. Um padrão barato não é um motivo. A Parte 3 é sobre essa armadilha.

A primeira fatura e o teto do plano gratuito

Custo é fácil de esquecer de dentro da IDE, então o Bullpen o coloca na arquitetura desde a primeira semana. No plano Hobby da Vercel, um mês inclui 4 horas de CPU ativa, 360 GB-horas de memória provisionada e 1 milhão de invocações de função. Cron jobs rodam no máximo uma vez por dia e disparam em qualquer ponto dentro da hora agendada.

A regra que molda o design é o que acontece depois desses números. Na maioria dos casos, uma funcionalidade que ultrapassa o limite espera 30 dias para voltar a funcionar. Para uma demo pública, uma funcionalidade pausada é uma indisponibilidade com 30 dias de tempo de recuperação. O Vercel Queues, no qual o Bullpen vai se apoiar, está em beta público desde fevereiro de 2026; se os limites mudarem quando ele sair do beta, esta fatura muda junto.

Por isso o repositório do Bullpen mantém um livro-caixa próprio: cada cota gratuita, com um link para a página que a declara, em cost/allowances.json, e um arquivo de uso por semana em cost/usage/. A landing page mostra o mesmo livro-caixa na seção de custos. O arquivo da semana 40 fica marcado como pendente até a semana fechar, em 4 de outubro, e então recebe os números reais.

Os primeiros cinco dias já dão uma linha de base. De 25 a 30 de setembro, os dois apps juntos usaram 431 invocações de função, 39 segundos de CPU ativa e 0,04 GB-hora de memória provisionada. Nenhum dos três chegou a 0,3% da cota mensal, e a fatura foi US$ 0,00. Essa é a parte fácil: um símbolo, uma chamada em cache a cada 5 minutos e ninguém negociando ainda.

O que mudaria minha opinião

A pergunta que esta parte deixa em aberto é a que o Bullpen obriga a enfrentar: uma liga de trading ao vivo em planos gratuitos precisa mesmo ser distribuída? Ainda não sei, e dois resultados resolveriam isso.

• Se o teste de carga de abertura de mercado na Parte 5 mostrar um único implantável atendendo 1.000 jogadores dentro do plano gratuito, com preços frescos o bastante, eu reverto os splits e digo isso.
• Se o teste da manhã ruim mostrar um feed morto impedindo a entrada de ordens, o isolamento de falhas está provado, e eu divido antes do planejado.

Até a Parte 5 rodar os dois testes, os cinco motivos são uma hipótese, e nenhum split entra no Bullpen sem um deles.