A volta do monolito: arquitetura na era da IA

Doze pessoas, 23 serviços

Eis um padrão que encontramos repetidamente em auditorias de arquitetura: uma startup de doze pessoas, nove delas na engenharia. A plataforma é composta por 23 microsserviços espalhados por 23 repositórios. Entre eles, quatro filas de mensagens, um service mesh e um punhado de bibliotecas compartilhadas feitas em casa, em três versões diferentes. Três dos nove engenheiros formam um "time de plataforma" cujo único trabalho é manter essa máquina de pé.

Quanto isso custa por feature? Pegue algo trivial: o cliente deve poder digitar um código de cupom no checkout. Nesse sistema, a mudança toca o serviço de checkout, o serviço de pricing, o serviço de pedidos e o BFF do frontend. Quatro repositórios, quatro pull requests, quatro deploys na ordem certa, uma atualização de contrato entre pricing e pedidos – e quando o primeiro teste falha, começa a caça no distributed tracing: qual dos quatro serviços engoliu o cupom?

Uma feature que seria uma tarde em uma única base de código leva uma semana aqui. Não porque a lógica seja difícil, mas porque a arquitetura fatia cada mudança em pedaços e os espalha por fronteiras de rede. O time comprou para si os custos de coordenação de uma grande corporação – sem a corporação.

Por que os microsserviços venceram os anos 2010

Para ser justo: microsserviços não venceram por burrice. Eles resolveram um problema real – só que raramente era um problema técnico.

Em 1967, Melvin Conway fez a observação que mais tarde ficou conhecida como lei de Conway: sistemas espelham a estrutura de comunicação da organização que os constrói. Se você tem cinquenta times que querem lançar de forma independente, precisa de uma arquitetura em que cinquenta partes possam ser implantadas de forma independente. O monolito, com seu único trem de release que todo mundo tinha de esperar, era um gargalo organizacional para Amazon, Netflix ou Spotify. Os microsserviços o removeram.

Some a isso ganhos técnicos genuínos: escalar hot paths de forma independente, linguagens diferentes para problemas diferentes, conter falhas em um único serviço. Tudo legítimo – na escala para a qual foi inventado.

Depois veio o cargo cult. Palestras de conferência de empresas com mil engenheiros viraram blueprints para times de dez. A pergunta "temos o problema que microsserviços resolvem?" foi substituída por "é assim que se faz hoje". A Netflix precisa de centenas de serviços implantáveis de forma independente. Uma startup de doze pessoas não precisa. Construiu mesmo assim, porque era essa a cara do modelo.

O pêndulo voltando também não é novidade. A Segment descreveu publicamente, já em 2018, como voltou de microsserviços para um monolito depois que o overhead operacional saiu do controle. Em 2023, o Amazon Prime Video relatou no próprio blog técnico que seu serviço de monitoramento de qualidade de áudio e vídeo havia sido migrado de um design serverless distribuído, baseado em Step Functions e Lambda, para um único processo – cortando os custos de infraestrutura em cerca de 90%. DHH e a 37signals pregam o "monolito majestoso" há anos. A Shopify roda uma das maiores bases de código Rails do mundo como um monolito deliberadamente modular.

O que é novo é que agentes de IA mudam duas entradas dessa equação ao mesmo tempo.

O que os agentes mudam, parte um: contexto

Um agente de código é exatamente tão bom quanto aquilo que consegue enxergar de uma vez. Isso não é nota de rodapé; é a propriedade que define essas ferramentas. Um agente que consegue seguir um caminho de chamada do handler HTTP, passando pela lógica de negócio, até a tabela do banco dentro de um único repositório toma decisões melhores do que um que bate numa fronteira de serviço e não encontra nada do outro lado.

Vistos por esse ângulo, microsserviços são uma arquitetura de contexto escondido. A lógica de uma única ação do usuário – "resgatar cupom" – está espalhada por N repositórios. Do repositório onde o agente começa, tudo o que ele vê é uma chamada HTTP para o vazio. O que acontece do outro lado, quais campos o contrato realmente espera, qual serviço dispara o efeito colateral que produz o bug: nada disso é visível de onde ele está. Ele precisa descobrir, clonar e correlacionar – supondo que tenha sequer credenciais para os outros repositórios.

Concretamente, um agente em um parque de microsserviços paga o imposto de integração duas vezes:

• Uma vez para descobrir. Quais serviços estão envolvidos? Onde mora o código? Qual versão do contrato vale agora – a do documento OpenAPI ou a que está de fato em produção? Na prática, contratos sempre derivam, e o agente só vê um lado.
• Uma vez para mudar. Quatro repositórios, quatro branches, quatro PRs que precisam combinar, quatro deploys com dependências entre si. Cada fronteira é um ponto onde uma inconsistência pode passar despercebida, porque nenhum compilador e nenhum sistema de tipos verifica através de uma fronteira de rede.

E há os testes. Em um monolito, um agente consegue rodar a suíte inteira localmente e saber em minutos se a mudança quebra alguma outra coisa. Em um parque de microsserviços, essa resposta só existe em um ambiente de integração que o agente normalmente não alcança – e que, sendo honesto, funciona só meio confiável para humanos também.

Relatos de praticantes e benchmarks iniciais deste ano apontam na mesma direção: agentes produzem mudanças multiarquivo mais corretas em monolitos modulares do que em parques de microsserviços, simplesmente porque o grafo de chamadas completo está visível em um repositório. Os números ainda são finos demais para precisão, mas o mecanismo é óbvio. Quem enxerga o campo inteiro joga melhor.

O que os agentes mudam, parte dois: tamanho do time

A segunda alavanca é organizacional, e ataca a lei de Conway de frente.

Em "O time de duas pessoas que substitui um departamento" descrevemos como agentes deslocam a produtividade de times pequenos: duas ou três pessoas hoje entregam o que há poucos anos exigia um departamento. Não é frase de marketing; é o que vemos nos clientes.

Levado às últimas consequências, isso significa: se três pessoas constroem o produto, não há fronteiras de time para uma arquitetura espelhar. Não existe um time de checkout que precise fazer deploy independentemente do time de pricing, porque não existem dois times. A razão organizacional para microsserviços – cadência de release independente para times independentes – simplesmente se dissolve para a vasta maioria das empresas. O que sobra é o custo.

A lei de Conway continua valendo. Só que agora a arquitetura espelha a organização real: um time pequeno, um sistema.

O monolito modular, concretamente

Para muita gente, "monolito" soa como a grande bola de lama da qual fugiram dez anos atrás. Não é disso que se trata. Trata-se do monolito modular: um único deployable, fronteiras internas rígidas.

O que isso significa na prática:

• Um deployable. Uma base de código, um build, um deploy. A feature do cupom é um PR, uma revisão, um release.
• Módulos com interface pública explícita. Checkout, pricing, pedidos, cobrança são módulos separados com APIs públicas claramente declaradas. O que não é exportado é invisível de fora – não por convenção, mas por regra.
• Fronteiras impostas. Lint de imports que faz o CI falhar numa violação. Ownership de módulo que define quem pode mudar uma interface. A Shopify construiu o Packwerk para isso; em outros ecossistemas, ferramentas como dependency-cruiser, ArchUnit ou os module boundaries do Nx fazem o trabalho.
• Um banco, ownership claro. Um schema por módulo, ou no mínimo uma regra inequívoca sobre qual módulo é dono de quais tabelas. Nenhum módulo escreve nas tabelas de outro; perguntas entre módulos passam pela interface.
• Assíncrono primeiro in-process. Eventos de domínio por um barramento interno, não por Kafka. O mesmo desacoplamento, sem a rede, sem a fila, sem o time de operações.
• Extrair só com motivo medido. Um módulo vira serviço apenas quando comprovadamente precisa escalar diferente, ser isolado diferente ou pertencer a outro time. Não antes, não por precaução.

E aqui está a virada que faz tudo isso funcionar justamente na era da IA. O motivo clássico pelo qual monolitos apodreciam nunca foi a arquitetura. Foram pessoas sob pressão de prazo pulando uma fronteira "só dessa vez": um acesso direto ao banco por fora do módulo, um import da pasta de internals porque era sexta à tarde. Cem decisões dessas depois, o monolito era uma bola de lama.

Exatamente esse tipo de disciplina é o que um agente entrega sem cansar. Ele nunca se entedia de respeitar uma regra de lint. Não pula uma fronteira porque o release é amanhã. Como revisor, aponta a centésima violação com a mesma consistência da primeira. A fraqueza em que monolitos historicamente falharam é precisamente a que um verificador incansável compensa. Isso torna o monolito modular não só viável de novo, mas pela primeira vez robusto contra a própria decadência.

Onde os microsserviços ainda vencem

Agora o contraponto honesto, porque "monolito para todo mundo" seria o mesmo cargo cult ao contrário.

Há casos em que microsserviços continuam sendo a resposta certa:

• Escala genuinamente independente. Transcodificação de vídeo e formulários CRUD não têm nada em comum – nem no perfil de recursos, nem na curva de custo, nem no hardware. Esses caminhos devem ficar separados.
• Isolamento regulatório ou de dados. Se dados de pagamento precisam viver numa zona PCI ou dados de saúde em infraestrutura própria, a fronteira de serviço é uma fronteira de compliance, não gosto arquitetural.
• Necessidade poliglota real. Um caminho de inferência de ML em Python ao lado de um sistema central em Go ou Java é motivo legítimo para dois deployables.
• Organizações acima de cerca de 100 engenheiros com cadências de release genuinamente independentes. Ali a lei de Conway vale na direção original, e a arquitetura deve refletir isso.
• Isolamento de raio de explosão para caminhos críticos. O login não pode cair porque o módulo de relatórios tem um vazamento de memória.
• Fronteiras com terceiros. Um gateway de API de parceiros que conversa com uma empresa externa é, por natureza, um sistema próprio.

Uma regra prática comum para 2026: monolito modular para algo entre 10 e 100 engenheiros; microsserviços acima disso, quando existem motivos reais de escala, poliglotismo ou isolamento. Regras práticas não são leis, mas essa mapeia a realidade da maioria das empresas melhor do que os blueprints dos anos 2010.

E um aviso que não pode ficar de fora: um monolito sem fronteiras mais um agente gerando código rápido é o caminho mais curto para uma grande bola de lama já inventado. Tudo o que foi dito acima sobre disciplina só vale se as fronteiras existirem e forem verificadas por máquina. Um agente escrevendo numa base grande sem regras de lint e sem estrutura de módulos produz em uma semana o acoplamento que um time humano levaria dois anos para criar. A arquitetura é o pré-requisito, não o subproduto.

Orientações práticas

Se você está começando um sistema hoje ou realinhando um existente, cinco regras servem bem:

1. Comece como monolito modular. Não como monolito com a intenção de adicionar módulos depois – a intenção não sobrevive ao primeiro sprint.
2. Fronteiras no primeiro dia. Estrutura de módulos, regras de import, arquivo de ownership, verificação no CI. O que fica para depois não vem.
3. Meça antes de extrair. Um serviço nasce de um resultado de profiler, de uma exigência de compliance ou de uma fronteira de time – nunca de um palpite.
4. Mantenha o contexto do agente pequeno, mesmo no monolito. Um README ou um AGENTS.md por módulo, descrevendo propósito, interface e regras. O agente então enxerga o todo quando precisa e o módulo quando basta. Isso se conecta ao que descrevemos em "A especificação é o novo código-fonte": a descrição do sistema vira o artefato primário com que o agente trabalha.
5. O caminho de volta dos microsserviços: strangler fig ao contrário. Primeiro consolide os repositórios em um monorepo – só isso já devolve a visibilidade ao agente sem mudar um único deployment. Depois traga de volta como módulos, um por vez, os serviços que não têm motivo medido para existir. A fronteira de rede vira fronteira de função, a fila vira evento in-process. Descrevemos em detalhe a abordagem para modernizar sistemas existentes em "Modernizando sistemas legados com agentes de IA".

Conclusão

Microsserviços resolveram um problema organizacional que a maioria das empresas nunca teve – e que as poucas que tinham estão perdendo agora para os agentes de IA. Se três pessoas entregam o que antes exigia um departamento, não sobram fronteiras de time para uma arquitetura espelhar. E se a ferramenta nova mais importante do stack trabalha melhor quando enxerga o sistema inteiro de uma vez, então uma arquitetura que espalha o contexto por vinte repositórios não é moderna. Está no caminho.

O monolito modular é a resposta pragmática: um deployable, fronteiras rígidas, um banco com ownership claro, e um agente impondo a disciplina em que os monolitos costumavam falhar. Microsserviços continuam sendo a ferramenta certa para problemas reais de escala, isolamento e organização – não para startups que copiaram um modelo da Netflix.

É por isso que na nh labs começamos sistemas novos como monolitos modulares com fronteiras desde o primeiro dia, e em parques de microsserviços existentes consolidamos primeiro os repositórios antes mesmo de falar em deployables. Não porque o monolito seja nostálgico. Mas porque a conta que o deslocou dez anos atrás hoje fecha diferente.