CERBERUS_01 / EXPERIMENTO 001 / ESTUDO INTRODUTÓRIO

Por que um monólito modular?

Uma arquitetura não é boa por ser popular. Ela precisa responder ao contexto. Vamos comparar duas opções para um sistema hipotético de reservas, sem transformar o exercício numa regra universal.

1. Cenário

Equipe de três desenvolvedores, baixo volume inicial, orçamento limitado e necessidade de publicar mudanças rapidamente. Existem os domínios Catálogo, Reservas e Notificações.

2. Duas alternativas

Critério	Monólito modular	Microsserviços
Implantação	Uma unidade de deploy com módulos internos.	Vários serviços com deploy independente.
Comunicação	Chamadas locais entre contratos de módulos.	Rede, APIs e possivelmente mensageria.
Consistência de dados	Transações locais podem simplificar operações.	Transações distribuídas exigem estratégias adicionais.
Operação	Mais simples para uma equipe pequena.	Mais componentes para observar, proteger e manter.
Evolução	Exige disciplina para manter limites internos.	Permite autonomia em certas condições, com custo de coordenação.

3. Hipótese e experimento

Hipótese: para a equipe e a carga descritas, um monólito modular com contratos explícitos minimiza o custo de operação e preserva espaço para evolução.

Desenhar três módulos independentes no código: catálogo, reservas e notificações.
Definir interfaces e proibir acesso direto entre camadas de persistência de módulos diferentes.
Implementar um fluxo de reserva e medir latência p95, taxa de erros e esforço de deploy.
Desenhar uma alternativa distribuída e comparar complexidade, limites de falha, infraestrutura e observabilidade.
Registrar um ADR com contexto, alternativas, decisão, consequências e gatilhos para reavaliar.

4. Conclusão provisória

Para esse cenário, começar com um monólito modular é uma hipótese plausível, não uma resposta universal. A escolha definitiva depende dos dados do experimento, da necessidade de independência entre equipes e dos requisitos de escala e confiabilidade.

← VOLTAR AO ROADMAP