Onde a Arquitetura Vira um Campo Minado
O problema não é microserviço. O problema é gente usando microserviço para resolver dor inventada. E aí começamos a ver equipes com 12 serviços para um produto que mal tem 200 usuários ativos. E o pior: ninguém sabe mais onde está a lógica de negócio. É tudo fragmentado.
Dívida técnica não nasce do código — nasce de decisões ruins tomadas cedo demais.
Vejo times sofrendo com:
- deploys coordenados que deveriam ser independentes;
- pipelines duplicadas por mania de isolamento;
- mais tempo criando governance do que entregando feature;
- call de 30 min para achar onde a regra realmente mora.
Isso não é arquitetura distribuída. Isso é só um monólito mal cortado — o famigerado monólito distribuído.
Como Resolver o Caos: Arquitetura Dirigida ao Contexto
O caminho não é voltar ao monólito por ressentimento, nem continuar no caos distribuído para pagar promessa ao hype. O caminho é desenhar limites reais, baseados em contexto de negócio, não em modinha.
As duas ferramentas mais subestimadas que resolvem 80% desse problema:
- Domain Breakdown: identificar capacidades de negócio antes de criar serviços.
- Contratos explícitos: cada serviço expõe aquilo que realmente é dono — nada além disso.
Sem isso, microserviço vira fantasia.
Implementação de Sênior: Mostrando o Corte Certo na Prática
Aqui vai uma modelagem simples e funcional para um serviço realmente isolado. Nenhuma gourmetização: apenas um contrato claro, autocontido, em OpenAPI.
openapi: 3.0.3 # Serviço: Billing (ele é dono da regra de cobrança)info: title: Billing Service version: 1.0.0paths: /charge: post: summary: Executa uma cobrança requestBody: required: true content: application/json: schema: type: object properties: userId: type: string amount: type: number responses: '200': description: Cobrança executada '400': description: Dados inválidosEsse serviço NÃO sabe nada de User Profile, de Orders ou de Notifications. Ele recebe input, aplica regra, retorna resultado. Simples. Escalável. Real.
Se você precisa ficar sincronizando o mesmo dado entre vários serviços, isso já é sinal de que seu corte está errado.
O Preço da Escolha: Microserviço Não é de Graça
Você paga caro — em operação, complexidade e tempo. Escolher microserviços só porque “é o que o mercado faz” é pedir para entrar em guerra com pouca munição.
Quando vale a pena?
- Times independentes trabalhando em domínios claros;
- Escalabilidade realmente assimétrica;
- Regra de negócio que precisa ser isolada por necessidade real.
Quando NÃO vale?
- Produto pequeno;
- Equipe mínima;
- Falta de clareza de domínio;
- Arquitetura ainda em descoberta.
Decisão arquitetural é contrato de longo prazo. Escolha com contexto, não com hype.
Direto das Trincheiras
- Comece monolítico e só quebre quando doer — não antes.
- Domínio mal definido = microserviço mal cortado.
- Todo serviço precisa de dono. Serviço sem dono vira entulho distribuído.
Fontes
Depois de passar um tempão como dev, tô começando a achar que …, Untitled, Migrando Sistemas Monolíticos – Sam Newman
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros hypes da nossa área.
Valeu e até a próxima! 😉
