Questa è una versione PDF del contenuto. Per la versione completa e aggiornata, visita:
Verrai reindirizzato automaticamente...
No panorama fintech de 2026, a velocidade de adaptação é a moeda mais valiosa. No entanto, para as instituições financeiras consolidadas, a inovação é frequentemente travada por décadas de estratificação técnica em mainframes. A migração de legado para microsserviços já não é uma simples escolha arquitetural, mas um imperativo de sobrevivência. Abandonar a abordagem arriscada do “Big Bang” a favor do padrão Strangler Fig representa a estratégia mais segura para modernizar sistemas críticos sem interromper a operação bancária.
Este guia técnico destina-se a CTOs e Lead Architects que devem orquestrar a transição de monólitos COBOL/Java para arquiteturas cloud-native em Kubernetes (GKE), gerindo a complexidade da consistência dos dados e a continuidade do serviço.
O setor bancário vive um paradoxo: deve oferecer experiências de utilizador fluidas como as dos Neobancos, mantendo, contudo, a estabilidade de sistemas core banking que processam milhões de transações por dia. As migrações do tipo “Big Bang” (reescrita completa e mudança imediata) têm historicamente taxas de falha superiores a 40%, com riscos inaceitáveis de downtime e perda de dados.
O padrão Strangler Fig (ou “Figueira Estranguladora”), teorizado por Martin Fowler, oferece a alternativa: envolver o sistema antigo com uma nova estrutura, intercetando as chamadas e reencaminhando-as gradualmente para novos microsserviços, até que o sistema antigo possa ser desligado em segurança.
O coração da estratégia Strangler Fig é a Facade (ou nível de interceção). Num contexto bancário moderno na Google Cloud Platform (GCP), este papel é tipicamente desempenhado por um API Gateway evoluído ou por uma Service Mesh.
Não comece por migrar o “Core Ledger”. Escolha funcionalidades periféricas de alto impacto para o cliente mas de baixo risco sistémico, como o Onboarding Digital ou a Visualização de Saldo. Utilize o Domain-Driven Design (DDD) para isolar estes contextos.
Antes de escrever uma única linha de código do novo microsserviço, posicione o API Gateway à frente do monólito. Inicialmente, o Gateway agirá como um simples proxy pass-through (100% do tráfego para o legado). Isto permite:
Desenvolva o novo microsserviço no GKE. Em vez de o ativar imediatamente, utilize uma estratégia de Shadowing (ou Dark Launching). A Facade duplica o tráfego de entrada: um pedido vai para o Mainframe (que responde ao utilizador), o outro vai para o Microsserviço (que processa o pedido, mas a sua resposta é descartada ou registada para comparação).
Isto permite verificar a correção da lógica de negócio do novo serviço com dados reais sem impactar o cliente.
O maior desafio na migração de legado para microsserviços no âmbito bancário é a gestão dos dados. Durante a transição, os dados devem residir tanto no DB2 do Mainframe como na nova base de dados cloud-native (ex: Cloud Spanner ou Cloud SQL), e devem ser sincronizados.
Fazer com que a aplicação escreva em ambas as bases de dados simultaneamente é um anti-padrão distribuído. Se a escrita no GKE for bem-sucedida mas a do Mainframe falhar, cria-se uma inconsistência grave.
A abordagem recomendada prevê o uso de uma pipeline de eventos assíncrona:
Isto garante a Eventual Consistency. Para operações críticas onde a consistência deve ser imediata, pode-se avaliar o padrão SAGA, mas a complexidade aumenta consideravelmente.
Uma vez validado o microsserviço em Shadow Mode, passa-se ao lançamento progressivo (Canary Release).
Configure o API Gateway para encaminhar uma percentagem mínima de tráfego (ex: 1% ou apenas utilizadores internos) para o novo serviço no GKE.
Num ambiente bancário, o rollback manual é demasiado lento. Implemente controlos de saúde avançados:
Frequentemente, o novo microsserviço precisará de dados que ainda residem no monólito e não foram migrados. Neste caso, o monólito deve expor APIs internas (ou ser consultado via JDBC/ODBC através de um nível de abstração) para servir estes dados ao microsserviço. É fundamental monitorizar a carga adicional que estas chamadas geram no Mainframe para evitar saturar os MIPS disponíveis.
A migração de legado para microsserviços através do padrão Strangler Fig não é um projeto “único”, mas um processo contínuo de refatorização. Para os bancos, esta abordagem transforma um risco existencial (a obsolescência tecnológica) numa vantagem competitiva, permitindo lançar novas funcionalidades de onboarding ou pagamentos instantâneos enquanto o backend é saneado progressivamente. A chave do sucesso não reside apenas na tecnologia (Kubernetes, Kafka), mas na disciplina operacional de gerir o período híbrido com observabilidade total e mecanismos de segurança automatizados.
O padrão Strangler Fig é uma estratégia de modernização arquitetural que substitui gradualmente um sistema legado monolítico. Em vez de uma reescrita completa imediata, envolve-se o sistema antigo com uma nova estrutura, intercetando as chamadas através de uma Facade e reencaminhando-as progressivamente para novos microsserviços. Esta abordagem reduz drasticamente os riscos operacionais típicos do setor bancário, garantindo a continuidade do serviço enquanto o sistema antigo é desativado peça por peça.
A gestão da consistência dos dados é crítica e não deve depender da dupla escrita síncrona, que pode causar desalinhamentos. A solução recomendada prevê o uso do Change Data Capture (CDC) combinado com uma pipeline de eventos assíncrona. Ferramentas específicas capturam as alterações na base de dados de origem e publicam-nas num barramento de mensagens, permitindo atualizar o sistema secundário em tempo quase real e garantindo a Eventual Consistency sem bloquear as transações.
O método Big Bang, que prevê a substituição instantânea de todo o sistema, comporta historicamente taxas de falha elevadas e riscos inaceitáveis de interrupção do serviço ou perda de dados. Pelo contrário, a migração gradual permite libertar valor de forma incremental, começando por funcionalidades de baixo risco. Este método permite testar as novas arquiteturas em Kubernetes com tráfego real limitado, facilitando o restauro automático em caso de anomalias.
O Shadow Traffic, ou Dark Launching, é uma técnica fundamental para validar a lógica de negócio dos novos serviços sem impactar o cliente final. O Gateway API duplica o pedido de entrada enviando-o tanto para o sistema legado como para o novo microsserviço. Enquanto a resposta do legado é enviada ao utilizador, a do microsserviço é descartada ou analisada apenas para comparação. Isso permite verificar a correção e o desempenho do novo código com dados reais em produção antes do lançamento efetivo.
O API Gateway, ou Facade, age como ponto de entrada único e desempenha o papel crucial de distribuir o tráfego entre o velho monólito e os novos microsserviços. Posicionando-o à frente do sistema existente antes de escrever novo código, permite normalizar a autenticação e obter visibilidade imediata sobre o tráfego. É o componente que torna possível o reencaminhamento gradual dos pedidos e a gestão das estratégias de lançamento como o Canary Release.