Em Resumo (TL;DR)
O padrão Strangler Fig oferece aos bancos uma estratégia segura para modernizar os monólitos legados evitando os riscos operacionais do Big Bang.
A integração de um nível Facade orquestra a transição gradual para microsserviços cloud-native mantendo intacta a operação dos sistemas críticos existentes.
Técnicas avançadas como o Change Data Capture garantem a consistência dos dados entre mainframe e cloud superando as armadilhas do dual-write.
O diabo está nos detalhes. 👇 Continue lendo para descobrir os passos críticos e as dicas práticas para não errar.
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.
1. O Paradoxo da Banca: Inovar sem Quebrar
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.
2. Arquitetura de Referência: O Nível de Interceção (The Facade)
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.
Componentes Chave da Arquitetura
- Mainframe Legado (AS/400 ou z/OS): O sistema de registo atual (SoR).
- Strangler Facade (API Gateway/Ingress): O ponto de entrada único para todo o tráfego de clientes. Decide se encaminha o pedido para o monólito antigo ou para o novo microsserviço.
- Microsserviços (GKE): Os novos serviços desenvolvidos em Go ou Java (Quarkus/Spring Boot), contentorizados e orquestrados no Google Kubernetes Engine.
- Anti-Corruption Layer (ACL): Um nível de tradução que impede que o modelo de dados do sistema antigo contamine o design dos novos microsserviços.
3. Estratégia de Implementação Passo-a-Passo
Fase 1: Identificação dos Bounded Context
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.
Fase 2: Implementação da Facade
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:
- Normalizar a autenticação (ex: passando de protocolos proprietários para OAuth2/OIDC).
- Obter observabilidade imediata sobre o tráfego existente.
Fase 3: Desenvolvimento e Shadow Traffic
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.
4. O Problema da Consistência de Dados: Dual-Write e CDC
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.
Porquê evitar o Dual-Write Síncrono
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 Solução: Change Data Capture (CDC)
A abordagem recomendada prevê o uso de uma pipeline de eventos assíncrona:
- O microsserviço escreve na sua própria base de dados.
- Um conector CDC (ex: Debezium ou ferramentas nativas GCP como Datastream) captura a alteração.
- O evento é publicado num barramento de mensagens (Kafka ou Pub/Sub).
- Um worker consome o evento e atualiza o Mainframe (ou vice-versa, dependendo de quem é o Owner do dado nessa fase).
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.
5. Lançamento e Rollback Automático
Uma vez validado o microsserviço em Shadow Mode, passa-se ao lançamento progressivo (Canary Release).
Configuração do Traffic Splitting
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.
Estratégia de Rollback Automatizado
Num ambiente bancário, o rollback manual é demasiado lento. Implemente controlos de saúde avançados:
- Métricas de Negócio: Se a taxa de conversões (ex: aberturas de conta) cair drasticamente no novo serviço, o rollback deve ser acionado automaticamente.
- Latência e Erros: Se a latência ultrapassar o limiar (SLA) ou os erros 5xx aumentarem, o Gateway deve reverter imediatamente 100% do tráfego para o Mainframe.
6. Gestão das Dependências de Legado
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.
Conclusões
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.
Perguntas frequentes
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.
Fontes e Aprofundamento
Achou este artigo útil? Há outro assunto que gostaria de me ver abordar?
Escreva nos comentários aqui em baixo! Inspiro-me diretamente nas vossas sugestões.