Padrão strangler fig: como substituir um sistema em produção

O padrão strangler fig é uma forma de substituir um sistema em produção de maneira gradual. Você coloca uma camada de roteamento na frente do sistema antigo e constrói as novas partes atrás dela, uma de cada vez. Quando cada parte nova fica pronta, você manda o tráfego para ela e aposenta o código antigo à medida que ele deixa de ser usado. O produto nunca para, e não existe um único dia de lançamento.

Usei essa abordagem quando liderei a migração completa de uma plataforma que se candidata automaticamente a vagas de emprego para seus usuários. Toda a arquitetura saiu de uma stack legada para uma nova enquanto as pessoas continuavam usando a plataforma todos os dias. Este artigo explica como o padrão funciona, na ordem em que eu o aplicaria, e onde ele não se encaixa.

O que é o padrão strangler fig e de onde vem o nome?

O nome vem das figueiras estranguladoras (strangler figs), plantas de floresta tropical que crescem em volta de uma árvore hospedeira. Ao longo dos anos, a figueira constrói sua própria estrutura em torno da árvore até que a árvore original desaparece e a figueira se sustenta sozinha. Martin Fowler emprestou a imagem no início dos anos 2000 para descrever a migração de software do mesmo jeito: fazer o sistema novo crescer em volta do antigo até que o antigo possa ser removido.

O contraponto é a reescrita big-bang. Numa reescrita, um time constrói o substituto em paralelo, normalmente por meses, e depois faz a virada numa única data. Tudo precisa bater com o comportamento antigo naquele dia, inclusive o comportamento que ninguém documentou. Reescritas tendem a custar mais e demorar mais do que a migração incremental, porque o sistema antigo precisa continuar rodando e mudando enquanto o novo é construído.

Com a abordagem strangler, você mantém o produto rodando e o migra parte por parte. Cada parte é pequena o bastante para ser testada, lançada e revertida de forma independente.

Como funciona o switch na frente do sistema antigo?

O switch é uma camada de roteamento que fica entre os usuários e os seus sistemas. Toda requisição passa por ela. A primeira versão não faz nada de esperto: encaminha 100% do tráfego para o sistema antigo. Esse é o objetivo. Você prova que a camada é segura antes que ela carregue qualquer risco.

É por aqui que eu começo, tanto na migração da plataforma de candidaturas quanto em qualquer sistema em produção que eu assumo. Antes de o switch existir, toda mudança é uma aposta. Depois que ele existe, toda mudança pode ser desfeita.

O que o switch precisa fazer

• Rotear por caminho ou funcionalidade. Por exemplo, requisições para um prefixo de URL ou para um endpoint de API vão para o serviço novo, e todo o resto vai para o antigo.
• Rotear por público. Mande primeiro os usuários internos, depois uma pequena parcela de usuários reais, depois todo mundo. É aqui que entram as feature flags e os rollouts no estilo canário.
• Voltar atrás na hora. O rollback deve ser uma mudança de configuração, não um deploy.
• Ser observável. Você precisa ver erros, latência e resultados por rota, separados entre antigo e novo.

O que ele pode ser

Depende do seu sistema:

• Um proxy reverso ou um load balancer funciona para aplicações web.
• Um API gateway funciona para backends baseados em serviços.
• Num produto com muito peso no frontend, o switch pode morar no próprio app, com flags decidindo qual implementação é renderizada.

Escolha a opção mais simples que seu time já sabe operar. O padrão não depende de uma ferramenta específica.

Como é uma migração strangler fig de verdade, passo a passo?

Esta é a sequência que eu sigo. O tempo exato varia de sistema para sistema, então não vou colocar datas.

1. Consiga acesso e entenda o que existe. Isso inclui repositórios, hospedagem, bancos de dados, DNS e contas de terceiros. Você não consegue rotear um tráfego que não controla.
2. Divida o sistema em fatias. Liste as funcionalidades voltadas ao usuário e os jobs em segundo plano. Cada fatia deve ter uma entrada e uma saída claras, por exemplo "login", "busca" ou "enviar notificação".
3. Instale o switch, mandando tudo para o sistema antigo. Lance ele sozinho. Se algo quebrar, você sabe que foi a camada e nada mais.
4. Escreva testes em torno do comportamento atual. Antes de substituir uma fatia, registre o que ela faz hoje, incluindo as esquisitices. Esses testes definem o que é "pronto".
5. Construa a primeira fatia na stack nova. Mantenha-a pequena e de baixo risco.
6. Rode em modo sombra, se puder. Mande cópias das requisições reais para o código novo e compare as respostas com as do antigo. Não mostre o resultado aos usuários ainda.
7. Libere aos poucos. Comece pelos usuários internos, depois uma pequena parcela, depois mais. Acompanhe as métricas em cada etapa e deixe o rollback pronto.
8. Aposente a fatia antiga. Quando ela passar um período razoável sem receber tráfego, apague o código. Pular esta etapa deixa você rodando dois sistemas para sempre.
9. Repita. Cada ciclo facilita o próximo, porque o switch, os testes e o monitoramento já existem.

A questão dos dados atravessa todas essas etapas, e é onde eu vi migrações ficarem mais difíceis. Ou os dois sistemas leem e escrevem no mesmo banco de dados por um tempo, ou você sincroniza os dados entre eles com algo como change data capture. Decida isso cedo, porque essa escolha define como você fatia o sistema.

Quais partes migrar primeiro e quais deixar por último?

A ordem importa mais que a velocidade. As primeiras fatias ensinam ao time como o sistema antigo realmente se comporta, então elas devem tolerar erros. Quando assumo uma base de código, sigo uma ordem fixa: primeiro o acesso, depois o build, depois os fluxos de dinheiro, depois os riscos. A ordem de migração abaixo segue a mesma lógica.

Por que os fluxos de dinheiro ficam para depois

Algumas partes do código cobram um cliente ou disparam uma ação que não pode ser desfeita. Esse código merece seu processo mais maduro. A essa altura, você já tem um switch funcionando, testes de comparação, dashboards e um rollback ensaiado. Migrá-lo primeiro significa aprender o padrão no seu código mais arriscado.

Existe um contrapeso. Se o maior problema do sistema antigo está no núcleo, deixá-lo para o fim pode significar que a migração nunca se paga. Nesse caso, começo pelas partes em volta do núcleo. Elas o encolhem e deixam suas bordas mais claras, e então eu ataco o núcleo com as melhores ferramentas já em funcionamento.

Quando o padrão strangler fig é a escolha errada?

Ele é um bom padrão inicial, mas não é universal. Se um sistema se encaixa em um destes casos, prefiro dizer isso logo de cara a forçar o padrão:

• Não existe um ponto de corte onde colocar o switch. Alguns apps desktop, sistemas embarcados ou monólitos muito acoplados não roteiam requisições por nada que você consiga interceptar. Talvez seja preciso criar esse ponto de corte primeiro, o que já é um projeto à parte.
• O sistema é pequeno. Se tudo pode ser reconstruído e verificado em pouco tempo, rodar dois sistemas em paralelo traz mais overhead do que economiza.
• A plataforma antiga vai ser desligada de qualquer jeito. Se o fornecedor vai encerrar o suporte numa data fixa, talvez você precise de um caminho mais rápido e mais direto.
• O antigo e o novo precisam de modelos de dados incompatíveis. Se manter os dados sincronizados é mais difícil que a própria migração, uma virada planejada com janela de manutenção pode ser a opção mais sensata.
• O time não consegue sustentar dois sistemas. O padrão significa manter os dois por um tempo. Se o time já está no limite, o período de transição pode doer.

Repare também no que o padrão não resolve. Se o problema é o próprio produto, uma migração limpa só te entrega o mesmo produto numa stack mais nova.

Como ele se encaixa num plano mais amplo de modernização de sistemas legados?

O padrão strangler fig é um método de entrega, não uma estratégia. Antes de escolhê-lo, você deveria saber três coisas: por que está modernizando, o que o sistema atual faz e o que você está disposto a deixar para trás. Uma auditoria de código e uma análise da sua dívida técnica vêm primeiro. As decisões entre replatforming, refatoração no lugar ou substituição vêm depois.

Em volta da migração em si, algumas práticas de apoio fazem a maior parte do trabalho:

• Feature flags para controlar quem vê o caminho novo.
• Deploys canário ou blue-green para reduzir o risco de cada liberação.
• Um plano de migração de banco de dados que cubra sincronização, validação e virada dos dados.
• Monitoramento que compare o comportamento antigo e o novo com números reais.

A regra que trago da migração da plataforma de candidaturas é simples: coloque o switch na frente de tudo antes de escrever código novo. Quando os usuários estão passando por uma camada que você controla, toda decisão seguinte fica menor e reversível.

Planejando uma migração?

Se você está avaliando esse padrão para um sistema em produção, mande um email para me@filipeeduardo.dev com uma descrição curta da stack e de onde dói. Fico feliz em trocar experiências e te dizer o que eu verificaria primeiro.