O debate entre microsserviços e monolito é um dos mais polarizados da engenharia de software. A verdade incômoda é que ambas as arquiteturas têm seu lugar — e escolher errado pode custar caro.
Monolitos não são ruins. Para a maioria dos projetos, especialmente nos estágios iniciais, um monolito bem estruturado é mais produtivo, mais simples de deployar, mais fácil de debugar e mais barato de operar. Empresas como Shopify rodam monolitos em escala massiva com sucesso. O segredo está na organização interna: módulos bem separados, boundaries claros e testes automatizados.
Microsserviços resolvem problemas de escala organizacional, não técnica. Se você tem times independentes que precisam deployar em ritmos diferentes, domínios de negócio completamente distintos que escalam de forma assimétrica, ou requisitos de tecnologia que variam drasticamente entre módulos — então microsserviços fazem sentido.
O custo real de microsserviços é frequentemente subestimado: orquestração de containers (Kubernetes), service mesh, distributed tracing, gestão de transações distribuídas, duplicação de dados, latência de rede entre serviços, complexidade de deploy, monitoramento e observabilidade. Se sua equipe tem menos de 15 pessoas, provavelmente o overhead não compensa.
Sinais de que é hora de migrar: deploys do monolito levam mais de 30 minutos, um bug em um módulo derruba todo o sistema, times diferentes estão constantemente em conflito de merge, ou partes do sistema precisam escalar de forma muito diferente (ex: processamento de imagem vs. API REST).
A abordagem mais segura é o "Strangler Fig Pattern": extraia um serviço por vez, começando pelos domínios com maior independência e menor acoplamento. Mantenha o monolito funcionando e migre gradualmente. Nunca faça um "big bang rewrite" — a taxa de falha é historicamente alta.
Se você está começando um projeto novo, comece com um monolito modular. Organize o código em módulos com interfaces claras entre eles. Quando a dor aparecer, você terá boundaries naturais para extrair serviços.