Strangler Fig Pattern na Prática: Como Migrar Sem Parar a Operação
Toda equipe que já tentou reescrever um sistema crítico do zero conhece a mesma história: o projeto começa com um cronograma otimista, atravessa um ano sem entregar nada visível para o negócio, e termina cancelado — ou pior, entregue tarde demais, competindo com um sistema legado que continuou evoluindo enquanto ninguém olhava.
O Strangler Fig Pattern resolve esse problema trocando a pergunta. Em vez de “como reescrevemos tudo sem quebrar nada”, a pergunta certa é “qual pedaço migramos primeiro, e como garantimos que os dois sistemas concordam entre si enquanto isso”. A segunda pergunta é mais difícil — e é sobre ela que praticamente ninguém fala em profundidade.
Este artigo assume que você já decidiu migrar de forma incremental. O foco aqui é onde a implementação realmente quebra na prática — e não é no roteamento. É nos dados.
O que é o Strangler Fig Pattern
O nome vem da figueira estranguladora, uma trepadeira que cresce ao redor de uma árvore hospedeira até substituí-la completamente — sem que a estrutura caia no processo. O padrão foi descrito por Martin Fowler em 2004, e a lógica é a mesma: você constrói funcionalidade nova ao redor do sistema legado, migrando responsabilidades aos poucos, até que o sistema antigo possa ser desligado com segurança.
Já detalhamos, no guia completo de modernização de legado, por que essa é a abordagem preferida em sistemas críticos frente ao rip-and-replace. E no artigo sobre os 7Rs da modernização, mostramos que o Strangler Fig é, na prática, a forma como Refactor, Rearchitect e Rebuild são executados com segurança — não uma estratégia concorrente a essas três, mas o método de implementação delas.
- Fachada (facade): camada intermediária, geralmente um API Gateway, que intercepta requisições e decide se elas vão para o sistema legado ou para o novo serviço.
- Coexistência: o período em que o sistema legado e o novo sistema operam simultaneamente, atendendo partes diferentes da mesma aplicação.
- CDC (Change Data Capture): mecanismo que captura mudanças no banco de dados legado e as replica, em tempo quase real, para o banco do novo sistema.
A arquitetura na prática: fachada, roteamento e decomposição
A camada de fachada
Todo o padrão depende de uma fachada — normalmente um API Gateway — posicionada entre o cliente (aplicação web, app mobile, integrações) e os dois sistemas. No início, a fachada roteia 100% do tráfego para o legado. À medida que módulos são extraídos, ela passa a direcionar requisições específicas para o novo serviço, enquanto o restante continua indo para o sistema antigo.
O cliente nunca sabe que a migração está acontecendo. Essa transparência é o que torna o padrão viável para sistemas com alto SLA — ninguém percebe a transição enquanto ela ocorre.
Roteamento incremental e canary release
Implementações mais maduras não migram 100% do tráfego de um módulo de uma vez. Usam roteamento ponderado: começam direcionando 1% das requisições para o novo serviço, validam estabilidade em produção real, e só então aumentam gradualmente até 100%. Isso reduz drasticamente o raio de impacto de qualquer bug que passe despercebido pelos testes.
| Camada | Ferramentas comuns | Função |
|---|---|---|
| Fachada / Gateway | API Gateway, Azure Front Door, Service Mesh | Interceptar e rotear tráfego entre legado e novo sistema |
| Sincronização de dados | Apache Kafka, RabbitMQ, ferramentas de CDC | Manter dados consistentes entre os dois sistemas |
| Observabilidade | Monitoramento full stack, tracing distribuído | Detectar divergência e falha em tempo real durante a coexistência |
O verdadeiro gargalo: sincronização de dados durante a coexistência
A parte do padrão que costuma ser subestimada não é o roteamento — é garantir que o sistema legado e o novo sistema concordem sobre o estado dos dados enquanto os dois estão ativos. Existem, essencialmente, duas abordagens.
Dual-write: consistência imediata, risco de falha parcial
Nessa abordagem, a aplicação escreve simultaneamente no banco legado e no banco novo. A vantagem é a consistência imediata — os dois sistemas ficam sincronizados no mesmo instante. O risco é operacional: se uma das duas escritas falhar e a outra for bem-sucedida, os sistemas divergem silenciosamente, e sem um mecanismo de compensação (como o padrão outbox), ninguém percebe até o dado errado aparecer em produção.
CDC (Change Data Capture): sem mexer na aplicação, com atraso a monitorar
O CDC captura as mudanças no banco de dados legado — geralmente via ferramentas como Debezium — e as publica como eventos em um message broker (Kafka, RabbitMQ), que o novo sistema consome para atualizar seu próprio banco. A vantagem é não precisar alterar o código da aplicação legada. A desvantagem é o atraso de replicação, que pode variar de segundos a minutos — e que precisa de verificadores de consistência monitorando continuamente para detectar e corrigir discrepâncias.
| Abordagem | Vantagem | Risco principal |
|---|---|---|
| Dual-write | Consistência imediata | Estados de falha parcial se uma escrita falhar |
| CDC (Change Data Capture) | Sem alteração no código legado | Atraso de replicação, exige monitoramento contínuo |
| Chamadas síncronas ao legado | Simplicidade inicial | Acopla o novo serviço à disponibilidade do sistema antigo |
Anti-Corruption Layer: isolando o novo sistema da sujeira do legado
Quando o novo serviço precisa escrever de volta no sistema legado, o erro comum é conectar diretamente ao banco de dados antigo. Isso quebra o isolamento do microsserviço e contamina o novo domínio com esquemas obsoletos. A alternativa mais robusta é o novo serviço emitir um evento de domínio limpo, que um worker especializado — a Anti-Corruption Layer — traduz para o formato (e para as regras) que o sistema legado espera.
Como estimar prazo e escopo
A pergunta mais comum de qualquer CIO patrocinando esse tipo de projeto é “quanto tempo vai levar”. Uma forma estruturada de aproximar essa resposta:
Tempo total = (número de funcionalidades a migrar × tempo médio de migração por funcionalidade) / (tamanho do time × fator de paralelismo)
Como referência de mercado: a estrangulação completa de um monólito grande — de porte equivalente a um sistema com mais de R$ 50 milhões em receita associada — costuma levar de 2 a 5 anos. Pode parecer longo, mas a diferença central frente a um rip-and-replace tradicional é que aqui o negócio recebe valor a cada módulo migrado, não só ao final.
Os erros mais comuns na implementação
O erro do rewrite-uri: por que aparecem 404 intermitentes
Um dos problemas técnicos mais frequentes — e menos documentados — na configuração de novas regras de roteamento é o erro de reescrita de URI (rewrite-uri) no API Gateway. Quando essa configuração está incorreta, o gateway anexa o caminho completo da fachada ao endereço do backend, gerando erros HTTP 404 intermitentes que parecem indisponibilidade do serviço novo, mas na verdade são erro de configuração de rota. Vale testar cada nova regra isoladamente antes de liberar tráfego real.
Prioridade errada: começar pelo módulo mais fácil, não o mais estratégico
É tentador migrar primeiro o que é tecnicamente mais simples. Mas, como já discutimos na matriz de priorização do guia de modernização de legado, a ordem certa considera valor de negócio e risco técnico — não facilidade de implementação.
Desligar o legado antes da hora
O sistema antigo só deve ser desativado depois de confirmar tráfego zero no módulo migrado — e não porque a migração “parece” concluída. Reverter a remoção de um objeto legado depois de desligado é significativamente mais custoso do que manter a validação um pouco além do necessário.
- O tráfego de produção no módulo está em zero por um período consistente?
- Existe monitoramento configurado para detectar clientes desatualizados tentando acessar a rota antiga?
- O plano de rollback ainda está disponível, mesmo que não seja mais necessário?
- A documentação do sistema reflete que aquele módulo não existe mais?
Quando o Strangler Fig Pattern não é a resposta certa
| Cenário | Recomendação |
|---|---|
| Sistema pequeno, baixa complexidade | Reescrever direto costuma ser mais eficiente que o overhead do padrão |
| Sem acesso ao código-fonte do legado | Avaliar Rehost ou substituição por solução de mercado |
| Necessidade de desligar o sistema antigo rapidamente | Migração incremental não é compatível com prazo curto |
| Sistema crítico, alta complexidade, operação não pode parar | Cenário ideal para o Strangler Fig Pattern |
Como a Framework aplica migração incremental na prática
No projeto com a Unimed-BH, já detalhado no guia de modernização de legado, o sistema CIH não tinha documentação nem cobertura de testes — o pior cenário para qualquer migração de dados. A Framework validou o comportamento do sistema com testes E2E completos antes de qualquer corte de tráfego, mantendo operação paralela e rollback planejado durante toda a transição. É a mesma lógica de coexistência controlada descrita neste artigo, aplicada com Self Repair rodando com squads que respondem pelo resultado.
A virada
O Strangler Fig Pattern não falha por causa do roteamento. Ele falha quando alguém trata a sincronização de dados como detalhe de implementação, em vez de tratá-la como a decisão arquitetural mais importante do projeto.
Se sua equipe já sabe que precisa migrar sem parar a operação, mas ainda não decidiu entre dual-write e CDC, essa decisão — não o cronograma — é o que vai determinar se o projeto entrega valor ano após ano ou vira mais um sistema “quase migrado” travado no meio do caminho.
Se isso faz sentido para o momento que sua empresa está vivendo, a nossa AI Session é o próximo passo.
Perguntas frequentes sobre o Strangler Fig Pattern
O que é o Strangler Fig Pattern?
É uma estratégia de modernização incremental em que uma camada de fachada roteia tráfego entre um sistema legado e um novo sistema, migrando funcionalidades aos poucos até que o legado possa ser desligado com segurança, sem interromper a operação.
Quanto tempo leva uma migração usando Strangler Fig?
Depende do número de funcionalidades e do tamanho do time, mas a estrangulação completa de um monólito grande costuma levar de 2 a 5 anos — entregando valor de negócio a cada módulo migrado, não apenas ao final.
Dual-write ou CDC: qual devo usar?
Dual-write oferece consistência imediata, mas cria risco de falha parcial se uma das escritas falhar. CDC evita alterar o código legado, mas introduz atraso de replicação que precisa ser monitorado. Para sistemas de missão crítica, CDC combinado com verificadores de consistência costuma ser a opção mais robusta.
É possível migrar sem downtime de verdade?
Sim. A camada de fachada torna a migração transparente para o cliente final, e o roteamento incremental (canary release) permite validar cada mudança com uma fração do tráfego real antes de expandir, reduzindo o risco de interrupção.
Quando não faz sentido usar o Strangler Fig Pattern?
Em sistemas pequenos e pouco complexos, quando não há acesso ao código-fonte do legado, ou quando existe necessidade de desligar o sistema antigo rapidamente — cenários em que o overhead do padrão supera seu benefício.
Como saber que já posso desligar o sistema legado?
Somente depois de confirmar tráfego zero e sustentado no módulo migrado, com monitoramento ativo para detectar clientes desatualizados tentando acessar rotas antigas, e com plano de rollback ainda disponível como precaução.