Primeiro, o que estamos comparando?
Um monólito é uma aplicação implantada como uma unidade. Isso não significa necessariamente código desorganizado: um monólito modular separa capacidades em módulos com APIs internas claras, propriedade de dados e dependências controladas. O processo de implantação é único, mas os limites internos podem ser rigorosos.
Microsserviços são serviços implantáveis e operáveis de forma independente, normalmente com responsabilidade e dados próprios. A independência permite que equipes alterem e escalem partes específicas, mas a comunicação passa pela rede. Uma chamada local que antes era simples pode falhar, atrasar ou ser repetida.
O custo invisível da distribuição
Suponha que criar um pedido exija consultar estoque e pagamento. Dentro de um monólito modular, essas operações ainda podem ter limites claros e, se usam o mesmo banco, participar de uma transação local quando apropriado. Em microsserviços, cada serviço possui seu armazenamento e o processo precisa lidar com estados intermediários, timeouts, retries e compensações.
Também surgem custos de infraestrutura: descoberta de serviços, telemetria distribuída, segurança entre serviços, configuração, pipelines, versionamento de contratos e plantão para falhas parciais. Esses custos não tornam microsserviços ruins; significam que autonomia precisa trazer valor suficiente para pagar a complexidade.
Quando o monólito modular é uma boa escolha
- O produto ou domínio ainda está sendo descoberto e os limites mudam com frequência.
- Uma equipe pequena consegue coordenar mudanças e implantações sem bloqueios recorrentes.
- A maior parte das operações precisa de consistência transacional simples.
- A operação distribuída consumiria mais tempo do que a equipe tem disponível.
- Os módulos podem ser isolados por contratos, testes e regras de dependência dentro do mesmo processo.
O monólito modular também é uma boa etapa evolutiva: permite validar limites de domínio antes de assumir o custo de separar processos. Se um módulo provar que precisa de escala ou implantação independente, ele pode ser extraído com entendimento melhor.
Quando microsserviços começam a fazer sentido
Microsserviços podem ser adequados quando há limites de negócio estáveis, equipes que precisam entregar de forma realmente independente, requisitos de escala muito diferentes entre capacidades, ou necessidades de disponibilidade e isolamento distintas. A independência deve ser real: uma mudança em um serviço não deveria exigir coordenar uma implantação simultânea de muitos outros.
O desenho também precisa de maturidade operacional. Métricas, logs correlacionados, tracing, automação, segurança e tratamento de falhas não são itens opcionais numa rede distribuída. Sem isso, autonomia arquitetural pode se transformar em diagnóstico lento e dependência entre equipes.
Como criar módulos que não sejam só pastas
Defina o que cada módulo possui e quais operações outros módulos podem solicitar. Evite que todos compartilhem livremente tabelas e entidades internas: isso cria um monólito acoplado mesmo quando os nomes das pastas parecem organizados. Use contratos de aplicação, eventos internos ou interfaces explícitas conforme a necessidade.
DDD pode ajudar a identificar contextos delimitados e a linguagem de cada área, mas não dita o processo de implantação. Veja o guia de DDD e contextos delimitados. A Clean Architecture complementa isso ao orientar dependências dentro de cada módulo.
Um roteiro de decisão simples
- Liste os problemas concretos que a divisão resolveria hoje.
- Verifique se os limites de negócio são compreendidos e se os dados podem pertencer a cada capacidade.
- Calcule custos de rede, operação, observabilidade e coordenação.
- Fortaleça primeiro os módulos internos e monitore conflitos e gargalos reais.
- Extraia um serviço quando houver benefício mensurável e capacidade operacional para mantê-lo.
Não escolha pela popularidade da arquitetura. O melhor desenho é aquele que permite ao produto e às equipes evoluírem com o menor custo total, considerando desenvolvimento e operação.