O monólito
Tudo o que você construiu até agora vive em uma única aplicação: um único processo que é compilado, testado e implantado como um bloco. Isso é um monólito. As camadas (controlador → serviço → repositório) estão dentro da mesma implantação e se chamam entre si com simples chamadas de funções.
O monólito tem grandes virtudes: é simples de desenvolver, depurar e implantar, e uma chamada interna é instantânea. Para a maioria dos projetos é a opção correta. Seus limites aparecem quando a equipe e o código crescem muito: tudo é implantado junto (uma mudança pequena obriga a reimplantar tudo) e você não pode escalar só a parte que precisa.
Microsserviços
A alternativa são os microsserviços: em vez de uma aplicação grande, muitos serviços pequenos e independentes, cada um responsável por uma parte do domínio (usuários, pagamentos, catálogo...). Cada serviço:
- Tem a sua própria implantação e o seu próprio ciclo de vida (é publicado sozinho).
- Costuma ter o seu próprio banco de dados (não compartilham tabelas).
- Comunica-se com os demais pela rede: HTTP/gRPC para chamadas diretas, ou mensagens assíncronas através de uma fila ou um barramento.
Assim, a equipe de pagamentos implanta quando quer sem tocar na de catálogo, e você pode escalar só o serviço sobrecarregado. O preço é uma forte complexidade operacional: a rede pode falhar, é preciso coordenar implantações, observar muitos serviços e viver sem transações que abranjam vários deles.
Arquitetura orientada a eventos
Acoplar serviços com chamadas HTTP diretas cria dependências rígidas: se A chama B, A precisa saber que B existe e esperar que ele responda. A arquitetura orientada a eventos (event-driven) inverte isso: em vez de chamar, um serviço publica um evento ("PedidoCriado") em um barramento de eventos, e outros serviços se inscrevem nos eventos que lhes interessam. É o padrão publicar/inscrever (pub/sub).
Pedidos ──(publica "PedidoCriado")──▶ Barramento de eventos
├──▶ Faturamento (inscrito)
└──▶ Email (inscrito)
O publicador não sabe quem está escutando: para adicionar uma nova reação (avisar a logística) basta inscrever outro serviço, sem tocar em Pedidos. Em troca você abre mão da consistência imediata: os inscritos reagem um pouco depois, então o sistema vive em consistência eventual (tudo acaba batendo, mas não no mesmo instante).
Sagas em alto nível. Quando uma operação abrange vários serviços (reservar estoque, cobrar, enviar) não há uma transação global. Modela-se como uma saga: uma sequência de passos onde, se um falha, executam-se ações de compensação que desfazem os anteriores. Na variante por coreografia, não há um coordenador central: cada serviço reage aos eventos dos demais e publica os seus.
Quando dar o salto?
| Vantagens | Desvantagens | |
|---|---|---|
| Monólito | Simples, rápido de desenvolver e implantar | É implantado e escalado como um bloco |
| Microsserviços | Escalonamento e implantação independentes, autonomia de equipes | Complexidade operacional, rede, consistência eventual |
Não é uma escolha de "melhor ou pior", mas de compromisso. A maioria dos sistemas começa como um monólito bem estruturado em camadas e só extrai microsserviços quando a dor da implantação conjunta e do escalonamento o justifica.