Você já viu um projeto crescer tanto que mexer em qualquer parte dele dava medo? Que fazer um deploy simples exigia testar o sistema inteiro? Esse é o problema que os microsserviços vieram resolver.
Primeiro, o que é um Monólito?
Antes de falar de microsserviços, precisa entender o que veio antes: o monólito.
Um monólito é um sistema onde tudo vive junto — cadastro de usuários, pagamentos, notificações, relatórios — em uma única aplicação, um único banco de dados, um único deploy.
No começo funciona muito bem. O problema aparece quando o sistema cresce:
- Uma mudança no módulo de pagamento pode quebrar o cadastro
- Para escalar só a parte de relatórios, você precisa escalar o sistema inteiro
- Times diferentes mexendo no mesmo código viram fonte constante de conflito
O que são Microsserviços?
Microsserviços é um estilo arquitetural onde você divide o sistema em serviços menores e independentes, cada um responsável por uma fatia do negócio.
Cada microsserviço:
- Tem sua própria responsabilidade (lembra do SRP do SOLID?)
- Roda de forma independente
- Tem seu próprio banco de dados
- Se comunica com os outros via API ou mensageria
- Pode ser desenvolvido, testado e publicado sem depender dos demais
Usando o petshop da Maya, do Pancho e do Romeu como exemplo, em vez de um sistema único teríamos:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ Serviço de │ │ Serviço de │ │ Serviço de │ │ Animais │ │ Agendamento │ │ Notificações │ │ │ │ │ │ │ │ • Cadastro │ │ • Consultas │ │ • E-mail │ │ • Histórico │ │ • Vacinas │ │ • WhatsApp │ │ • Prontuário │ │ • Banho/Tosa │ │ • Push │ └─────────────────┘ └─────────────────┘ └─────────────────┘
Cada caixinha é um sistema independente. Se o serviço de notificações cair, os agendamentos continuam funcionando.
Vantagens
Escalabilidade independente: Se o serviço de agendamentos está sobrecarregado na segunda-feira de manhã, você escala só ele — sem tocar nos outros.
Times autônomos: Cada time cuida do seu serviço com liberdade para escolher tecnologia, linguagem e ritmo de deploy.
Resiliência: Uma falha em um serviço não derruba o sistema inteiro. O resto continua de pé.
Deploy sem medo: Publicar uma nova versão do serviço de notificações não exige testar o cadastro de animais.
Desafios (e não são poucos)
Microsserviços não são bala de prata. Eles trocam a complexidade do código pela complexidade da infraestrutura e da comunicação.
Comunicação entre serviços: Agora os serviços precisam se falar. Isso significa lidar com latência, falhas de rede e consistência de dados distribuídos.
Observabilidade: Em um monólito, um erro tem um log. Em microsserviços, uma requisição pode passar por 5 serviços diferentes. Rastrear o que deu errado exige ferramentas específicas como distributed tracing.
Consistência de dados: Cada serviço tem seu banco. Garantir que os dados estejam sincronizados entre eles é um dos maiores desafios da arquitetura distribuída.
Complexidade operacional: Você passa a gerenciar múltiplos deploys, múltiplos bancos, múltiplas configurações. Ferramentas como Docker e Kubernetes se tornam essenciais.
Monólito vs Microsserviços: qual escolher?
| Monólito | Microsserviços | |
|---|---|---|
| Complexidade inicial | Baixa | Alta |
| Escalabilidade | Todo o sistema junto | Serviço por serviço |
| Deploy | Um só | Independente por serviço |
| Time pequeno | ✅ Ideal | ❌ Pode ser excessivo |
| Sistema grande | ❌ Vira gargalo | ✅ Ideal |
| Maturidade necessária | Baixa | Alta |
⚠️ Microsserviços para um time de 2 pessoas e um sistema pequeno é over-engineering. Comece simples. Evolua quando a dor do monólito for real.
A regra de ouro
Microsserviços resolvem problemas de escala — de sistema e de time. Se você não tem esse problema ainda, provavelmente não precisa dessa solução ainda.
O caminho mais saudável costuma ser: comece com um monólito bem estruturado (com Clean Architecture e SOLID, como vimos nos posts anteriores) e extraia microsserviços quando a necessidade aparecer de verdade.