A forma como dividimos um sistema afeta como ele escala, como é implantado e como a equipe trabalha. Duas abordagens principais: monolito e microsserviços.
Arquitetura monolítica
Todas as funções do negócio estão em uma única aplicação, implantada como uma unidade e normalmente com um único banco de dados.
Vantagens:
- Simples de desenvolver, testar e implantar no início.
- Menor curva de aprendizado e custo operacional.
- Chamadas internas rápidas, sem rede entre as partes.
Desvantagens:
- Escala como um todo: não dá para escalar só o módulo que precisa.
- Alto acoplamento: uma mudança pode afetar o sistema todo.
- Implantações maiores e mais arriscadas; uma falha pode derrubar tudo.
Arquitetura de microsserviços
Cada função do negócio é um serviço pequeno e independente, com seu próprio código, implantação e, em geral, seu próprio banco de dados. Os serviços se comunicam por APIs (HTTP/REST, gRPC) ou mensageria.
Vantagens:
- Escalabilidade independente por serviço.
- Equipes autônomas e implantação independente.
- Isolamento de falhas e liberdade de tecnologia por serviço.
Desvantagens:
- Complexidade operacional: orquestração, monitoramento, rastreamento distribuído.
- Consistência de dados e transações entre serviços é difícil.
- Latência e falhas de rede entre serviços.
- Exige maturidade em DevOps, contêineres e automação.
Comparativo
| Critério | Monolito | Microsserviços |
|---|---|---|
| Implantação | Única | Por serviço |
| Escalabilidade | Do todo | Por serviço |
| Complexidade | Menor | Maior |
| Equipe ideal | Pequena a média | Várias equipes |
| Banco de dados | Compartilhado | Um por serviço |
Qual escolher
Para um produto novo ou equipe pequena, comece por um monólito bem organizado. Divida em microsserviços quando houver necessidade real (escala, times independentes). Uma opção intermediária é o monólito modular: um único deploy, mas com módulos bem separados, que facilitam uma migração futura.