Chega de Big Bang: Como o Strangler Fig Pattern salva migrações de sistemas legados

Substituir um sistema de grande porte construído como um monólito é um dos maiores desafios de engenharia que uma empresa pode enfrentar. A tentação de fazer um “Big Bang” — reescrever tudo do zero e virar a chave de uma vez — é enorme. Mas, na prática, essa abordagem costuma rimar com prazos estourados, bugs catastróficos em produção e noites sem dormir.

Existe um caminho muito mais seguro, elegante e incremental: o Strangler Fig Pattern (ou Padrão da Figueira Estranguladora).

Neste artigo, vamos entender como aplicar esse padrão na prática, migrando o seu sistema de forma controlada, rota por rota.

O que é o Strangler Fig Pattern?

O termo foi cunhado por Martin Fowler após uma viagem à Austrália, onde ele observou o comportamento das figueiras estranguladoras. Essas plantas começam a crescer nos galhos superiores de uma árvore hospedeira. Conforme suas raízes descem até o chão e sua copa se expande, ela envolve gradualmente a árvore antiga até que, eventualmente, a hospedeira morre e apenas a nova árvore permanece.

Trazendo isso para a arquitetura de software: em vez de desligar o monólito antigo para colocar o novo sistema, nós criamos o sistema novo em paralelo e vamos interceptando as requisições aos poucos. O monólito vai encolhendo até que possa ser completamente desativado.

Os 3 Pilares da Estratégia

De forma simplificada, a migração com o Strangler Pattern se resume a três passos cíclicos:

1. Transformar (Transform): Criar um novo componente ou microsserviço que reescreve uma funcionalidade ou rota específica do monólito.
2. Coexistir (Coexist): Fazer os dois sistemas rodarem ao mesmo tempo em produção.
3. Eliminar (Eliminate): Redirecionar 100% do tráfego daquela funcionalidade antiga para a nova e remover o código obsoleto do monólito.

Na Prática: Estrangulando Rota por Rota

Imagine que temos um e-commerce monolítico rodando na rota raiz /. Queremos extrair o módulo de busca de produtos (/busca) para um microsserviço dedicado e moderno. Como fazer isso sem que o usuário final perceba?

1. A Peça-Chave: O Interceptador (Proxy ou API Gateway)

Para o padrão funcionar, você precisa de uma fachada na frente dos seus sistemas. Pode ser um Nginx, um API Gateway (como Kong, AWS API Gateway, Spring Cloud Gateway) ou até mesmo um sistema dinâmico de roteamento baseado em Feature Flags.

Inicialmente, a regra de roteamento é simples:

ANY / → Encaminha para o Monólito

2. Desenvolvendo o Novo Serviço

A equipe cria o novo microsserviço de busca. Ele é testado individualmente e publicado no ambiente de produção. Ele está pronto, mas ainda não recebe tráfego real do cliente final.

3. Mudando o Roteamento Dinamicamente

Agora vem a mágica da coexistência. No seu Gateway ou gerenciador de tráfego, você atualiza a regra:

GET /busca → Encaminha para o Novo Microsserviço de Busca

ANY / (demais rotas) → Continua indo para o Monólito

Dica de Ouro: Fazer essa virada de chave usando ferramentas de Feature Flags / Canary Releases permite que você envie primeiro apenas 1% do tráfego para a nova rota de busca. Se algo quebrar, você desliga o switch imediatamente e o tráfego volta para o monólito em milissegundos, sem necessidade de um novo deploy (rollback).

4. O Estrangulamento Contínuo

Uma vez que a rota /busca está estável no microsserviço, o código de busca dentro do monólito tornou-se "morto". Você pode limpá-lo.

O ciclo então se repete para as próximas etapas:

• Extrair o carrinho de compras (/carrinho)
• Extrair o fluxo de checkout (/checkout)

Com o tempo, o monólito perde todas as suas funções até que a última rota seja migrada. Pronto! O monólito foi completamente estrangulado.

Vantagens dessa abordagem

• Redução drástica de risco: Se a nova rota falhar, o impacto é isolado a apenas uma funcionalidade, e a reversão é instantânea.
• Valor contínuo para o negócio: A empresa não precisa “parar de entregar novas features por 1 ano” para reescrever o sistema. O sistema novo gera valor desde a entrega da primeira rota.
• Melhoria na moral do time: Entregar pequenas partes em produção com frequência traz muito mais segurança e satisfação para o time de engenharia do que esperar um grande lançamento incerto.

Cuidados Importantes

Nem tudo são flores. Ao adotar o Strangler Fig, fique atento a:

• Sincronização de Banco de Dados: Se o monólito e o novo microsserviço precisarem dos mesmos dados, você precisará de estratégias de replicação de dados ou APIs de integração temporárias para garantir que os bancos não fiquem dessincronizados.
• Gerenciamento do Gateway: A camada de proxy passa a ser o seu ponto único de falha (Single Point of Failure). Ela precisa ser altamente escalável e resiliente.

Conclusão

Estrangular um monólito exige paciência, disciplina e as ferramentas certas de gerenciamento de tráfego e visibilidade. No entanto, é a estratégia mais segura do mercado para modernização de sistemas legados de forma sustentável.

Para ver exemplos mais detalhados de código, diagramas de infraestrutura e entender como mitigar riscos em migrações usando flags de forma inteligente, acesse o artigo completo:

👉 **Padrão Strangler Fig na Prática: Estrangulando seu Monólito Rota por Rota no Blog da Flagly**