Modernização de legado
Um core de crédito que não pode parar
O problema
Uma financeira que opera originação e cobrança sobre o mesmo monólito há mais de uma década chega a um ponto conhecido: cada release exige janela noturna e plantão, e por isso os releases vão ficando raros. O trabalho é tirar a originação de dentro do monólito com ele ainda no ar, até o deploy deixar de ser um evento de risco.
Onde esse problema aparece
Aparece em financeiras, meios de pagamento e operações de crédito cujo sistema central concentra cadastro, motor de decisão, contratos e cobrança no mesmo banco de dados, com integração ponto a ponto para cada parceiro ou convênio.
Por que ele custa caro
O roadmap comercial passa a depender de mudanças no motor de crédito, e o time evita tocá-lo. Habilitar um convênio novo leva semanas de trabalho manual. O custo real não é infraestrutura — é a lentidão para responder a uma oportunidade de mercado.
As restrições que moldam a decisão
A originação roda em horário bancário e não pode parar. Regra de crédito tem exigência regulatória de rastreabilidade: toda decisão precisa ser reconstruível depois. E é comum que ninguém no time atual tenha escrito o código original.
Como abordamos
Descartamos a reescrita total: ela concentra todo o risco no futuro, num sistema que ninguém domina por inteiro. Começamos por observabilidade e testes de caracterização sobre o motor de decisão, porque sem eles qualquer extração é aposta. Só então aplicamos strangler fig, com um proxy na borda roteando a originação para o serviço novo convênio a convênio e o monólito como fallback.
O que costuma ser construído
Um serviço de originação com motor de regras versionado e decisões auditáveis, um proxy de roteamento por convênio e um barramento de eventos para manter cadastro e cobrança consistentes durante a convivência entre o novo e o antigo. A esteira de deploy passa a rodar em qualquer horário, com rollback por convênio.
Como trabalhamos junto
Squad conjunto: engenheiros nossos e do cliente no mesmo board e no mesmo ritual. Cada decisão arquitetural vira um ADR curto, escrito para ser lido por quem chegar depois. As últimas extrações são conduzidas pelo time do cliente, com a gente só na revisão.
O que muda quando funciona
Convênio novo passa a entrar sem alteração no monólito. O deploy deixa de exigir janela e plantão, e a frequência de release volta a ser decisão de produto, não de risco operacional. E o time interno sai capaz de conduzir sozinho as extrações seguintes — que é o critério de sucesso que costumamos combinar logo na primeira conversa.
Reconhece esse problema no seu contexto? Vamos conversar.
Agendar uma conversa