O monólito modular voltou

Semana passada eu fiz o oposto do que todo diagrama de arquitetura dos últimos dez anos recomendava: peguei três serviços que se falavam por HTTP, com seus repositórios, seus pipelines e seus dashboards separados, e juntei tudo num único deployable. Um monólito modular, com fronteiras internas explícitas, mas um processo só. O sistema ficou mais rápido, mais barato de operar e mais fácil de raciocinar. E me forçou a nomear, sem anestesia, o que a distribuição tinha me cobrado durante todo esse tempo.

O que ela prometia era autonomia de time. O que ela entregou foi latência de rede, um tracing distribuído que eu mantinha só pra entender bugs que antes eram um stack trace, e três deploys que precisavam de uma reunião pra sair na ordem certa. A autonomia existia no diagrama. No organograma, era o mesmo time abrindo três pull requests.

Microserviço é um empréstimo, não uma compra

A forma como a indústria vendeu microserviço foi como escolha de escala: seu sistema cresceu, logo você fatia. Isso inverte a causa. Microserviço não é uma resposta a volume de tráfego, é uma resposta a volume de gente. A fronteira de processo que você cria entre dois serviços é, antes de tudo, uma fronteira entre duas equipes que precisam deployar sem pedir licença uma à outra.

O que você compra com essa fronteira é independência de deploy. O que você paga é tudo que deixou de ser uma chamada de função: serialização, timeout, retry, idempotência, versionamento de contrato, observabilidade distribuída. Isso é o juro. E juro se paga todo mês, tenha o time crescido ou não.

O erro não foi adotar microserviço. Foi tratá-lo como uma compra à vista quando era um financiamento. Você assina o custo operacional no dia um. O benefício, a autonomia, só começa a pingar quando existem times independentes de verdade pra colher. Abaixo desse tamanho, você está pagando as prestações de um carro que nunca sai da garagem.

A conta que ninguém somava

A parcela que passava despercebida era a cognitiva. Um bug que atravessava dois serviços deixava de ter um stack trace e passava a ter uma investigação. Uma mudança de contrato que num monólito o compilador pegava virava um incidente em produção três semanas depois, quando o consumidor esqueceu de atualizar. Cada uma dessas coisas é pequena. Somadas, elas são o custo operacional que o diagrama nunca mostra, porque diagrama desenha caixas e setas, não plantões.

Distribuição não resolve acoplamento. Ela troca o acoplamento que o compilador via por um que só a produção revela.

Service mesh é o retrato disso. A adoção que subia todo ano começou a encolher, e não por moda: a camada existia pra domar uma complexidade que, pra maioria, era autoinfligida. Quando você tira os serviços, a necessidade do mesh some junto. Não é que a ferramenta era ruim. É que ela resolvia um problema que a arquitetura tinha criado.

O que os dados começaram a admitir

O sinal mais honesto é a reconsolidação virar tendência, não vergonha. Não é mais caso isolado: uma parte grande dos times que fatiou anda revendo esse corte e trazendo serviços de volta pra dentro. O caso mais citado é o da Prime Video, que juntou um pipeline serverless num serviço único e reportou algo perto de 90% de corte no custo de operação. O detalhe importante não é o número. É que quem cortou não era um time pequeno sem musculatura. Era gente com toda a musculatura, admitindo que a distribuição custava mais do que rendia naquele caso.

Isso não é “o monólito venceu”. É mais desconfortável que isso. É reconhecer que compramos distribuição antes de ter a organização que a justificasse, e que boa parte da complexidade que passamos anos domando era uma dívida que nós mesmos originamos.

Microserviço continua sendo uma boa arquitetura. Só não pra quem ele foi vendido. A pergunta nunca foi “meu sistema aguenta?”. Era “meu organograma preenche essas fronteiras, ou elas vão existir só no diagrama?”.