Monólito, microsserviço ou modular: 3 topologias, 3 diagramas, uma decisão
A escolha entre monólito, microsserviços e monólito modular não é sobre qual é "melhor" — é sobre onde você quer pagar o custo de complexidade: no código ou na rede.
Toda discussão sobre "monólito vs microsserviços" comece do jeito errado quando trata as duas opções como os únicos pontos do mapa. Existe uma terceira topologia no meio do caminho, e ela resolve o problema que motiva boa parte das migrações precipitadas pra microsserviços. A consequência de ignorá-la: times pequenos pagando o custo operacional de uma arquitetura distribuída sem o volume de time ou de tráfego que justificaria esse custo.
Monólito clássico
Tudo roda num processo só, compartilhando o mesmo banco de dados. Vantagem: deploy simples, debug direto (uma stack trace, um lugar só pra olhar), transação local de verdade sem precisar coordenar múltiplos serviços. Custo: qualquer mudança exige rebuild e redeploy do sistema inteiro, e módulos que deveriam ser independentes acabam se acoplando por conveniência — afinal, tudo está a uma chamada de função de distância.
Microsserviços
Cada módulo vira um serviço independente, com seu próprio banco de dados, implantado e escalado separadamente. Vantagem: times conseguem trabalhar e implantar em paralelo sem pisar no trabalho um do outro; cada serviço escala de acordo com sua própria demanda. Custo: toda chamada que antes era função virou chamada de rede — com toda a latência, falha parcial e complexidade de consistência que isso carrega. Esse custo é real e permanente, não desaparece com boa engenharia, só é gerenciado por ela.
Monólito modular
Mesmo processo, mesmo banco — mas com fronteiras internas explícitas entre módulos, reforçadas por convenção de código ou por ferramenta de lint arquitetural, não só por rede. Na prática, isso significa que um módulo só fala com o outro através de uma interface definida, nunca acessando direto a tabela ou a classe interna de outro módulo.
É, em outras palavras, o meio-termo: qualquer módulo que realmente precisar de deploy e escala independentes no futuro já está com fronteira clara o bastante pra virar um serviço separado sem reescrever o sistema inteiro do zero. O custo de acoplamento acidental do monólito clássico cai, sem pagar ainda o custo de rede dos microsserviços.
Como decidir, na prática
- Time pequeno, poucos módulos com ciclo de vida parecido: monólito clássico resolve, e migrar cedo demais pra microsserviços só adiciona operação sem resolver problema real
- Módulos com necessidade clara de escalar ou implantar de forma independente, mas ainda sem certeza de onde estão as fronteiras: monólito modular deixa a decisão de separar em serviço pra quando a fronteira já estiver validada em produção
- Múltiplos times, ciclos de deploy desacoplados e volume que justifica a complexidade operacional extra: microsserviços resolve um problema que já existe, em vez de um problema hipotético
Nenhuma das três é a escolha "madura" ou a escolha "legada" — são três formas de pagar o mesmo custo de complexidade, em momentos e lugares diferentes do sistema. A pergunta certa nunca é qual topologia é melhor; é qual delas seu time e sua base de usuários atual realmente sustentam.
