Strangler Fig Pattern: como migrar um sistema legado para o Lambda sem downtime

O problema

Quase todo time de engenharia tem um sistema desse tipo: rodando há anos, que ninguém gosta de tocar, mas que fatura todo santo dia. É esse cenário que Sascha M. descreve na quinta parte de sua série sobre padrões de migração, publicada no DEV Community na seção #aws: um aluguel de bicicletas fictício chamado Radhafen, cuja aplicação inteira roda como um monólito Node.js único, acessível em https://legacy.radhafen.example.

O reflexo mais comum diante desse tipo de sistema é a reescrita completa. Na experiência do autor, essa reescrita costuma terminar com dois sistemas que precisam de manutenção ao mesmo tempo: o legado continua vivo enquanto o novo já virou dívida técnica. Para quem migra workload legado na AWS, essa é a armadilha mais cara: parar tudo, prometer um switch-over e descobrir no meio do caminho que o comportamento do sistema antigo nunca foi documentado por completo.

O padrão strangler fig, batizado por Martin Fowler a partir das figueiras-estranguladoras que ele viu nas florestas de Queensland, propõe outra rota. São plantas que brotam no alto de uma árvore, mandam raízes pelo tronco e, com os anos, envolvem o hospedeiro até ele desaparecer, enquanto a figueira segue de pé sozinha. Aplicado a software, isso significa construir o sistema novo ao redor do antigo e tomar suas responsabilidades aos poucos, uma rota de cada vez, até poder desligar o que sobrou.

O risco reduzido e o valor antecipado da abordagem gradual compensam seu custo.

the reduced risk and earlier value from the gradual approach outweigh its costs.Martin Fowler, citado por Sascha M. na série do DEV Community

Nem toda migração pede esse cuidado. Para uma aplicação pequena, com três endpoints, reescrever num fim de semana costuma ser mais rápido do que montar qualquer fachada. O padrão compensa quando pelo menos dois destes pontos valem para o seu sistema: ele é grande e mal documentado, o negócio não aceita congelar features por meses, parar o ar nem que seja por um fim de semana está fora de cogitação, e a interface externa é HTTP, o que permite colocar um proxy na frente. Fica difícil quando o legado conversa principalmente com outros sistemas através de um banco de dados compartilhado: aí não existe porta para colocar a fachada.

A arquitetura

No exemplo da Radhafen, o primeiro recorte escolhido é o cálculo de preço, POST /quotes: não lê dados de outros módulos, não escreve nada, é chamado com frequência e é fácil de testar. Reservas, que dependem de estações, pagamentos e faturas, ficam para depois, quando a fachada já tiver se provado. O fluxo completo funciona assim:

1. O cliente envia POST /quotes para uma HTTP API do API Gateway, que funciona como fachada única na frente de todo o sistema.
2. O API Gateway compara a requisição com as rotas cadastradas; como existe uma rota exata para POST /quotes, ela vence qualquer rota genérica e qualquer $default.
3. Essa rota aciona a função Lambda quote-handler. Em modo shadow, ela chama o legado via HTTPS (função callLegacy), calcula o próprio resultado (computeQuote), compara os dois (diffResults) e grava a diferença no CloudWatch Logs, mas devolve ao cliente a resposta do legado.
4. Quando o time confia na taxa de acerto registrada nos logs, troca o parâmetro migrationMode de shadow para live e roda npm run deploy de novo; a variável de ambiente MIGRATION_MODE muda, e a partir daí o Lambda responde com seu próprio cálculo sem mais chamar o legado para essa rota.
5. Qualquer requisição sem rota própria, como POST /reservations, cai na rota $default, que o API Gateway encaminha como integração HTTP_PROXY direto para https://legacy.radhafen.example, sem alterar nada.
6. Quando uma rota some do tráfego real, o time apaga o endpoint correspondente do código legado: essa é a fase de aposentadoria, que só acontece depois que a rota nova já provou, em produção, que responde igual ou melhor que a antiga.

Se uma rota nova apresenta problema, basta apagar a rota do serverless.yml e reimplantar: o tráfego volta automaticamente para o $default e, portanto, para o legado. Esse é o rollback embutido do padrão, e é também o motivo de ele ser mais seguro do que um corte único.

Os serviços envolvidos

A fachada inteira usa poucos serviços gerenciados, o que é parte do argumento do autor: não é preciso nenhum serviço dedicado de orquestração de migração para montar isso.

• API Gateway (HTTP API): mais barata e mais simples que uma REST API para encaminhamento puro; é ela quem decide, por precedência de rota, se a requisição vai para Lambda ou para o legado.
• AWS Lambda: roda em nodejs22.x, arquitetura arm64, com 256 MB de memória e timeout de 10 segundos no exemplo; o Node.js 22 já traz fetch nativo, então o cliente para o legado não precisa de dependência extra.
• CloudWatch Logs: recebe os eventos parallel-run com o campo match e a lista de diferenças; é a fonte de verdade para decidir quando trocar de shadow para live. O serverless.yml do exemplo define logRetentionInDays: 14, o que evita acumular log de comparação indefinidamente.
• CloudFormation, via Serverless Framework v4: como o evento httpApi só oferece integração proxy para Lambda, a integração HTTP_PROXY e a rota $default precisam ser declaradas como recursos AWS::ApiGatewayV2::Integration e AWS::ApiGatewayV2::Route à mão.

Vale registrar uma mudança de catálogo que afeta diretamente essa arquitetura: o Migration Hub Refactor Spaces, serviço da AWS que montava esse tipo de fachada de forma gerenciada, não aceita novos clientes desde 7 de novembro de 2025. A documentação da AWS aponta o AWS Transform como alternativa. Na prática, isso empurra quem está planejando uma migração deste tipo para montar a fachada à mão, como no exemplo da Radhafen, já que a infraestrutura necessária é pouca.

Trade-offs

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

O código de transição (o modo shadow, o cliente para o legado, a função de comparação) é peso morto depois que a migração termina, e isso tem custo de excelência operacional: alguém precisa manter, testar e depois remover esse código, numa cadência que normalmente não existe no roadmap. O autor compara isso a andaime de obra: ninguém reforma uma casa sem andaime só porque ele vai ser desmontado no final.

No pilar de confiabilidade, a rota $default como rede de segurança é também um ponto cego: se uma rota nova falha silenciosamente e cai de volta para o legado sem ninguém notar, o time perde visibilidade de que a migração estagnou. O parallel run ajuda a mitigar exatamente isso, mas só funciona para operações sem efeito colateral; não dá para criar uma reserva duas vezes só para comparar, então seams com escrita de dados compartilhados (como reservas, que dependem de estações, pagamentos e faturas) ficam de fora do modo sombra e exigem outra estratégia de validação.

Há também um limite técnico que vira trade-off de eficiência de desempenho: a integração de uma HTTP API não aceita timeout acima de 29 segundos, porque o limite total da API é 30 segundos. Para endpoints legados mais lentos que isso, o autor aponta, na mesma série, o padrão de job assíncrono com retorno 202 e fila SQS (tema do primeiro artigo da série) como alternativa, fora do escopo deste texto.

No pilar de otimização de custos, o modo sombra custa dobrado por definição: toda requisição de uma rota em comparação aciona o Lambda e o sistema legado ao mesmo tempo, porque o legado continua sendo a fonte de verdade enquanto o novo cálculo só roda para auditoria. Isso é temporário, mas precisa entrar na conta de quem está planejando o cronograma da migração.

Por fim, no pilar de segurança, o exemplo pressupõe que o legado é alcançável publicamente via HTTPS; a própria fonte reserva uma seção à parte do artigo original para sistemas privados, sem detalhar a solução no trecho reproduzido aqui. Quem tem o legado atrás de uma VPC deve tratar isso como ponto em aberto antes de replicar o desenho tal como está.

Custo estimado

A fonte não traz nenhum número de fatura para o exemplo da Radhafen, nem estimativa de tráfego, então não há como citar um valor em reais ou dólares com honestidade. O que dá para afirmar, a partir da própria arquitetura descrita, é a estrutura do custo: uma HTTP API cobra por requisição processada, cada invocação do Lambda cobra por chamada e por tempo de execução, e o CloudWatch Logs cobra por volume de log ingerido e retido.

O ponto prático para quem orça essa migração é que o modo shadow soma, não substitui: enquanto uma rota está em comparação, o time paga a chamada ao legado (que já pagava antes) mais a invocação do Lambda, mais o log de cada parallel run. Esse custo extra é temporário por natureza e some assim que a rota entra em modo live, mas vale dimensionar o período de observação (dias ou semanas) em vez de deixá-lo aberto indefinidamente, até porque é esse período que paga duas vezes pela mesma resposta.

Como adaptar

Para quem está migrando um workload legado de verdade, a ordem sugerida pelo autor é um bom ponto de partida: primeiro recortes sem efeito colateral e com dado próprio, depois funcionalidades novas construídas direto no sistema novo, e só no final os processos centrais que compartilham dado com o legado. Essa ordem existe para que o time aprenda a confiar na fachada antes que um erro saia caro.

Se o seu time não usa Serverless Framework, o equivalente em CDK ou Terraform é direto: uma aws_apigatewayv2_integration do tipo HTTP_PROXY apontando para a URL do legado, uma aws_apigatewayv2_route com route_key igual a $default, e uma rota específica por função Lambda que for assumindo responsabilidades. A lógica de precedência (rota exata vence {proxy+}, que vence $default) é do próprio API Gateway, não do framework, então o comportamento se mantém em qualquer ferramenta de IaC.

Algumas perguntas valem ser respondidas antes de replicar esse desenho em produção:

• O seu legado é alcançável por HTTPS, ou está atrás de uma VPC? Se estiver atrás de VPC, é preciso resolver o acesso privado antes de montar a integração HTTP_PROXY, algo que a fonte original aponta mas não detalha no trecho disponível.
• Alguma rota candidata ao strangler fig tem resposta que passa de 29 segundos? Se sim, ela não serve para integração direta de HTTP API e pede o padrão assíncrono citado acima.
• Existe alguma operação com efeito colateral que você precisa migrar antes de ter confiança nela? Se sim, o parallel run não se aplica e é preciso outra forma de validação, como réplica de dados ou ambiente de sombra completo.

O ganho real de aplicar esse padrão numa migração não é técnico, é organizacional: cada rota movida é um commit pequeno, revisável e reversível, em vez de uma virada de chave única que só se testa de verdade no dia da produção.

Fonte

1. DEV Community — #aws: Strangler Fig Pattern: Migrate to Lambda Step by Step

Fonte: DEV Community — #aws