ADR: Monolito Modular vs Microsserviços num Fintech Greenfield

Toda decisão de arquitetura é uma função das forças que atuam sobre o sistema num dado momento. Ignorar essas forças e aplicar um padrão porque ele é "moderno" ou porque a empresa de referência do setor o usa é uma das formas mais comuns de acumular dívida técnica prematura.

Neste cenário, as forças são claras e, em parte, contraditórias:

Velocidade de validação do negócio. A fintech ainda não sabe exatamente quais são seus bounded contexts reais. O domínio de pagamentos parece óbvio, mas os limites entre "conta", "carteira", "limite de crédito" e "transação" só se tornam claros depois de múltiplas iterações com clientes reais. Definir fronteiras de serviço antes de entender o domínio é o erro que Martin Fowler descreve com precisão cirúrgica em MonolithFirst: você distribui a complexidade antes de compreendê-la, e refatorar fronteiras entre microsserviços é ordens de magnitude mais custoso do que mover módulos dentro de um monolito.

Tamanho e capacidade do time. Com 4–7 engenheiros, cada hora de engenharia é escassa. Microsserviços introduzem overhead operacional imediato e não-trivial: pipelines CI/CD por serviço, service discovery, observabilidade distribuída (traces correlacionados, log aggregation, métricas por serviço), gestão de versões de API, eventual consistency entre serviços, e circuit breaking. Esse overhead existe independentemente de o sistema estar em produção ou não. Em times pequenos, esse custo é pago inteiramente antes de qualquer feature de negócio ser entregue.

Blast radius e isolamento de falhas. Aqui microsserviços têm vantagem real: uma falha no serviço de notificações não derruba o processamento de pagamentos. Num monolito, um bug em código de baixa criticidade pode, se mal isolado, afetar todo o processo. Esse argumento é legítimo, mas sua força depende diretamente de quão bem o monolito é estruturado internamente. Um monolito modular com separação clara de responsabilidades, tratamento de erros por módulo e circuit breakers internos reduz significativamente esse risco sem exigir infraestrutura distribuída.

Requisitos regulatórios. PCI-DSS e as normas do Bacen exigem segregação de dados de portadores de cartão, auditabilidade de acessos e, eventualmente, isolamento de rede para componentes que processam dados sensíveis. Isso cria pressão real por separação, mas essa separação pode ser endereçada com isolamento de módulo + criptografia em repouso e em trânsito + controles de acesso granulares dentro de um monolito, pelo menos no estágio inicial. A separação física em serviços distintos pode ser adiada sem violar requisitos regulatórios desde que os controles compensatórios estejam presentes.

O argumento mais comum a favor de microsserviços desde o início é o de que "é mais fácil começar certo do que refatorar depois". Esse argumento tem uma premissa implícita que raramente é examinada: que você sabe o que é "certo" antes de ter clientes reais.

Na prática, os bounded contexts de uma fintech emergem do uso real. O que parece ser um domínio de "contas" no dia 1 frequentemente se divide em "conta corrente", "conta de pagamento", "conta de investimento" e "limite de crédito rotativo" depois de seis meses de feedback de produto. Se você já construiu quatro microsserviços separados com seus próprios bancos de dados, APIs e pipelines, essa refatoração tem um custo de coordenação enorme: migrações de dados distribuídas, versionamento de APIs, janelas de manutenção coordenadas entre serviços, e risco de inconsistência transacional durante a transição.

Num monolito modular bem estruturado, a mesma refatoração é uma operação de movimentação de código dentro de um repositório, com um único banco de dados para migrar e um único artefato para redesploy. O custo é uma fração.

Isso não significa que microsserviços são errados, significa que eles são uma solução para um problema de escala organizacional e técnica que a maioria das fintechs greenfield ainda não tem. A Lei de Conway é real: sua arquitetura vai refletir a estrutura de comunicação do seu time. Com 5 engenheiros, a estrutura de comunicação ótima é um único time coeso trabalhando num único artefato com fronteiras internas claras. Distribuir artificialmente esse time em "times de serviço" antes de ter escala para isso é uma forma de criar overhead de coordenação sem os benefícios correspondentes.

O padrão MonolithFirst de Fowler não é uma recomendação de nunca usar microsserviços. É uma recomendação de ganhar o direito de usá-los: entender seu domínio suficientemente bem para cortar as fronteiras corretas, e ter o time e a maturidade operacional para pagar o custo de operá-los.

A decisão por monolito modular só tem valor se vier acompanhada de disciplina arquitetural explícita. Sem ela, a velocidade inicial se transforma em dívida estrutural em 12–18 meses, e a extração futura se torna tão custosa quanto teria sido a distribuição prematura.

Separação de schemas no banco de dados. Cada módulo acessa exclusivamente seu próprio schema no PostgreSQL. Queries cross-schema são proibidas via code review e, idealmente, via usuário de banco de dados separado por módulo (cada módulo tem um role PostgreSQL com GRANT apenas no seu schema). Isso simula o isolamento de dados que teríamos com bancos separados em microsserviços, sem o custo de gerenciar múltiplas instâncias RDS.

Interfaces internas formalizadas. Módulos não chamam diretamente classes ou funções de outros módulos. A comunicação é feita exclusivamente via interfaces públicas definidas na camada de ports (Hexagonal Architecture). Isso garante que, no momento da extração, a interface já existe e pode ser convertida em uma chamada HTTP ou mensagem de evento sem refatoração estrutural.

Testes de arquitetura automatizados. Ferramentas como ArchUnit (Java) ou equivalentes em TypeScript (dependency-cruiser) são configuradas no pipeline de CI para falhar o build se uma dependência cross-módulo não-autorizada for introduzida. Essa é a única forma de garantir que a disciplina de fronteiras se mantém conforme o time cresce e a pressão por features aumenta.

Event bus interno como preparação para extração. A comunicação assíncrona entre módulos (ex: Payments publica PaymentCompleted, Notifications consome e envia o recibo) é feita via um event bus in-process. A interface desse bus é idêntica à que seria usada com EventBridge ou SNS/SQS. Quando o módulo de Notifications for extraído, a única mudança é substituir a implementação do bus por uma chamada real ao EventBridge, o código do produtor e do consumidor permanece inalterado.

Critérios de extração documentados e revisados. A decisão de extrair um módulo não deve ser tomada por pressão de momento ou por "já que estamos aqui". Os critérios são definidos agora: bounded context estável por dois trimestres, time acima de 10 engenheiros, ou requisito técnico específico (escala diferenciada, blast radius inaceitável, requisito regulatório de isolamento de rede). Esses critérios são revisados trimestralmente na reunião de arquitetura.