Radar Tech: microservices viraram dívida organizacional disfarçada de arquitetura — e a IA mudou o cálculo

O assunto que mais movimentou as comunidades de engenharia nas últimas 24 horas foi uma frase incômoda, que viralizou em vários canais de arquitetura: microservices são dívida organizacional disfarçada de arquitetura. Não é uma tese nova — é o velho "Monolith First" de Martin Fowler voltando ao centro do debate, agora com uma variável nova na equação: agentes de IA escrevendo boa parte do código.

O que "Monolith First" nunca disse

A leitura preguiçosa do argumento é "microservices são ruins". Não é isso. O ponto original é de sequência, não de valor: quase todo sistema de microservices que deu certo começou como um monolito que cresceu e foi decomposto. Quase todo sistema projetado como microservices desde o primeiro commit terminou em apuros.

O motivo é direto: microservices só funcionam quando as fronteiras estão certas. E fronteiras certas são o resultado de aprendizado sobre o domínio — algo que quase ninguém tem no dia zero. Errar uma fronteira em um monolito é um refactor; errar uma fronteira entre dois serviços é uma migração com contrato, versão, rollout e risco de produção.

A virada de 2026: o preço de mover a fronteira caiu

Durante uma década, a regra foi "comece monolítico porque refatorar serviço é caro demais". O que mudou é que a parte caríssima de decompor — reescrever contratos, mover código, acompanhar consumidores, gerar testes de paridade — passou a ser feita, em boa medida, por agentes de IA. O prêmio de microservices (o overhead de operar um conjunto de serviços) continua existindo, mas o custo de corrigir uma fronteira errada caiu.

Isso não significa "decomponha tudo agora". Significa que a decisão muda de forma. Se antes a pergunta era "qual arquitetura final eu escolho?", agora ela é:

• Onde os limites são incertos? Se o domínio ainda está sendo descoberto, comece concentrado — é onde a IA ajuda mais a mover código depois.
• Onde a escala ou o time já exigem separação? Se os limites são estáveis e conhecidos, decomponha com contrato explícito.
• Qual o custo do erro em cada direção? Fronteira errada em monolito = refactor. Fronteira errada em serviços = incidente de produção.

O que não terceirize para o gerador de código

A variável nova traz uma armadilha simétrica. Se a IA torna trivial mover código entre serviços, ela também torna trivial criar acoplamento invisível: um import cruzado aceito no meio de um patch, uma chamada direta a um banco que "sempre funcionou". Quando o código é gerado em volume, a fronteira real do sistema passa a divergir da fronteira declarada — e é aí que a arquitetura vira narrativa.

Por isso a decisão de decomposição precisa virar registro explícito. Um ADR de fronteira de serviço não documenta o desenho bonito do slide; ele registra o que não pode atravessar cada fronteira e por quê. É o contrato que permite dizer "isto está errado" sem depender da memória de quem escreveu o trecho — ou de qual modelo o gerou.

O que fazer na prática

• Registre a decisão, não só o diagrama. Cada fronteira aceita precisa de um ADR com contexto, alternativas rejeitadas e consequências.
• Trate a fronteira como contrato testável. Se nada verifica que o serviço A não escreve na tabela do B, a fronteira é decorativa.
• Meça o prêmio, não o hype. O overhead operacional de um serviço a mais tem custo real de on-call, deploy e observabilidade. Decomponha quando o ganho paga esse preço.
• Preserve o caminho de volta. Toda decomposição deveria ser reversível; se não for, é aposta, não decisão.
• Use a IA para mover código, não para escolher fronteiras. A decisão de onde cortar é de quem entende o domínio; o agente executa a migração sob contrato.

O ponto que amarra o debate: a IA não responde "monolito ou microservices". Ela torna a segunda decisão — decompor, recompor, mover limite — mais barata, e por isso a primeira decisão — registrar por que a fronteira existe — mais importante. Quem registra a intenção mantém o controle; quem deixa a fronteira emergir do gerador de código descobre o custo no próximo incidente.

O catálogo já tem pacotes de ADR que aplicam exatamente essa lógica — decisão com contexto, alternativas rejeitadas e consequências verificáveis. É o mesmo princípio: evidência antes de afirmação, decisão registrada antes do código.