Architectural Decision Story · ADS-01
Monólito modular ou microsserviços
Em quais condições cada abordagem faz sentido?
Contexto
Um produto com muitos domínios — financeiro, estoque, pedidos, CRM — construído por um time enxuto, com necessidade de consistência entre domínios.
Problema
Microsserviços prometem autonomia e escala independente, mas cobram coordenação distribuída, consistência eventual e uma operação muito mais cara.
Alternativas consideradas
- Monólito modular
- Um time ou poucos times, domínios que precisam de transações em conjunto, necessidade de refatorar fronteiras com frequência.
- Microsserviços
- Times autônomos com ciclos de entrega independentes, requisitos de escala muito diferentes por domínio, maturidade de operação distribuída.
- Monólito sem fronteiras
- Raramente: protótipos descartáveis. O custo aparece quando o produto sobrevive.
Trade-offs
- Transações ACID entre domínios versus escala independente por serviço.
- Refatorar uma fronteira é mover código, não versionar contratos de rede.
- Disciplina de fronteira depende de revisão e testes, não do compilador ou da rede.
Decisão
Começar com módulos de fronteiras explícitas no mesmo deploy e extrair serviços apenas quando houver uma pressão real e mensurável — de time, de escala ou de isolamento de falha.
Consequências
- Um módulo defeituoso pode afetar a aplicação inteira: validação prévia e testes por módulo tornam-se obrigatórios.
- Escala acontece na aplicação como um todo até que um domínio justifique extração.
Aprendizados
- A pergunta certa não é “qual arquitetura é moderna”, e sim “qual custo de coordenação o time consegue pagar”.
- Fronteiras bem desenhadas no monólito são o que torna uma extração futura barata.