Quando microsserviços são a decisão errada

A pergunta chega quase sempre no mesmo formato: "estamos avaliando migrar para microsserviços, o que vocês recomendam?". A resposta honesta costuma frustrar — na maioria dos casos, não recomendamos. Não porque microsserviços sejam ruins, mas porque o problema que a empresa descreve raramente é o problema que microsserviços resolvem.

O problema que microsserviços realmente resolvem

Microsserviços resolvem um problema de autonomia. Quando cinco times precisam entregar em ritmos diferentes e todos dependem do mesmo pipeline, do mesmo ciclo de release e do mesmo banco de dados, a coordenação vira o gargalo. Separar em serviços com propriedade de dados independente permite que cada time entregue sem esperar os demais.

Perceba que a formulação é organizacional, não técnica. O ganho aparece quando existem times suficientes para que a coordenação custe mais do que a operação distribuída. Com dois times e oito pessoas, esse ponto ainda não chegou.

O que costuma ser confundido com necessidade de microsserviços

• "O deploy é arriscado" — isso é falta de teste automatizado e de pipeline confiável. Distribuir o sistema multiplica os deploys arriscados em vez de eliminá-los.
• "O código está uma bagunça" — separar em serviços não organiza o código; transforma acoplamento em chamada de rede, que é a forma mais cara de acoplamento.
• "Precisamos escalar" — quase sempre uma parte específica precisa escalar. Escala horizontal do monolito ou extração de um único serviço resolve, sem distribuir tudo.
• "O time é lento" — investigue o processo de entrega antes da arquitetura. Indicadores DORA respondem essa pergunta melhor do que um diagrama.

O custo real da distribuição

Ao distribuir, você troca chamadas de método por chamadas de rede. Chamada de rede falha, demora e chega duas vezes. Isso significa que passam a ser obrigatórios: idempotência, retry com backoff, circuit breaker, rastreamento distribuído, versionamento de contrato, consistência eventual e um ambiente local que consiga subir mais de um serviço.

Distribuir um sistema não elimina complexidade — move a complexidade do compilador, onde ela é verificada, para a rede, onde ela vira incidente de produção.

O caminho intermediário que quase ninguém considera

O monolito modular entrega a maior parte do benefício com uma fração do custo. Módulos com fronteiras explícitas, comunicação interna por interface, esquemas de banco separados por módulo e testes de arquitetura que quebram o build quando alguém atravessa uma fronteira.

1. Trace as fronteiras de domínio com Event Storming, antes de qualquer decisão de infraestrutura.
2. Materialize essas fronteiras como módulos dentro do mesmo artefato, com dependências verificadas no CI.
3. Separe os esquemas de banco por módulo, proibindo join entre eles.
4. Opere assim por alguns meses — as fronteiras erradas vão aparecer, e corrigi-las ainda é barato.
5. Extraia como serviço apenas o módulo com necessidade concreta de autonomia ou escala independente.

Errar uma fronteira dentro do monolito modular custa uma refatoração de um dia. Errar a mesma fronteira já distribuída custa uma migração de dados, uma mudança de contrato e uma janela de indisponibilidade.

Quando recomendamos distribuir

• Existem times suficientes para que a coordenação seja comprovadamente o gargalo — e isso aparece nos números de lead time.
• Uma parte do sistema tem perfil de carga radicalmente diferente do resto.
• Um domínio precisa de isolamento de falha por exigência regulatória ou contratual.
• A maturidade de observabilidade e automação já existe. Distribuir sem ela é trocar um problema por cinco.

A pergunta certa não é "monolito ou microsserviços". É: qual a menor mudança estrutural que remove o gargalo real de hoje? Na maior parte das vezes, a resposta é bem menos dramática do que a migração que estava sendo cogitada.