Core Banking modular: por que monólitos bem desenhados vencem microsserviços prematuros

Todo projeto de core bancário eventualmente enfrenta a mesma pergunta: microsserviços desde o dia um, ou um monólito modular que evolui para serviços conforme a necessidade real aparece?

O erro mais comum

Decompor por camada técnica (um serviço de "banco de dados", outro de "regras", outro de "API") em vez de por domínio de negócio. O sintoma é sempre o mesmo: para fechar uma conta, você precisa orquestrar chamadas síncronas entre cinco serviços diferentes, e uma falha em qualquer um deles derruba a operação inteira.

Limites de contexto que funcionam na prática

Em plataformas de core bancário maduras, os limites que se mantêm estáveis ao longo do tempo são:

• Contas & Ledger — a fonte de verdade contábil, isolada e auditável.
• Meios de Pagamento — PIX, boletos, TED, cartões: cada um com seu próprio ciclo de vida, mas compartilhando o mesmo ledger.
• Crédito — motor de decisão e gestão de contratos, com forte necessidade de versionamento de regras.
• Compliance — KYC, AML e reporte regulatório, que precisa observar todos os domínios sem acoplar-se a eles.

Modular monolith como ponto de partida

Começar com um monólito modular — módulos com fronteiras de código bem definidas, comunicando-se por contratos internos claros — permite evoluir para serviços independentes exatamente nos pontos onde a escala ou o time exigem, sem pagar o custo de rede e consistência eventual onde ele não traz benefício.

A decomposição em microsserviços deixa de ser dogma e passa a ser uma decisão de engenharia, tomada com dados de carga e organização de times — não com modismo.