Por que a promessa de reescrever seu sistema legado do zero é uma das maiores armadilhas da engenharia de software e como migrar incrementalmente com segurança.
Todo engenheiro ou líder técnico já viveu ou presenciou este momento: o sistema legado se tornou lento, difícil de manter, o deploy é um evento traumático de madrugada e a base de código virou um emaranhado de dependências. Em uma reunião executiva, alguém sugere a frase mágica: "Vamos parar tudo e reescrever o sistema do zero em microsserviços modernos."
A intuição diz que começar do zero com uma folha em branco será mais rápido e limpo. A realidade de campo nos mostra exatamente o contrário: a reescrita Big Bang é uma das formas mais eficientes de queimar orçamento, exaurir times e falhar.
Enquanto a nova versão é desenvolvida por meses (ou anos), o negócio não para. Novas regras são adicionadas ao monólito legado todos os dias. A nova arquitetura nasce correndo atrás de um alvo móvel e, quando finalmente fica pronta, já nasce defasada e repleta de bugs que o legado já havia superado há uma década. Para escapar dessa armadilha, a resposta da arquitetura de software é o Padrão Strangler Fig (Figueira Estranguladora).
O Conceito: A Figueira que Abraça o Hospedeiro
Batizado por Martin Fowler em homenagem às árvores figueiras que germinam nos galhos mais altos de uma árvore hospedeira e crescem suas raízes em direção ao solo até envolver e substituir gradualmente a estrutura original, o padrão Strangler Fig propõe uma transição 100% incremental:
- Interceptar: Todas as requisições passam por uma camada de roteamento na borda (API Gateway ou Reverse Proxy).
- Coexistir: Novas funcionalidades ou módulos extraídos são implementados na nova arquitetura, convivendo harmoniosamente com o monólito.
- Substituir: O tráfego para aquela funcionalidade específica é desviado para o novo microsserviço. O código antigo no monólito é desativado e, eventualmente, removido.
O usuário final não faz ideia de que parte do sistema roda no legado e parte roda no novo ecossistema distribuído. O valor de negócio é entregue desde a primeira sprint.
O Cenário do Desastre: O Desafio Real dos Dados
Criar uma rota nova em um microsserviço e colocar um proxy na frente é a parte fácil. O verdadeiro teste de fogo do Strangler Fig está na camada de persistência.
No monólito, o banco de dados geralmente é altamente acoplado por Foreign Keys, Triggers e Stored Procedures. Se o novo microsserviço precisar dos dados de clientes, você se depara com um dilema perigoso: compartilhar o banco legado (criando um falso microsserviço acoplado) ou criar um banco novo isolado e sofrer para manter a consistência.
Se você tentar migrar o banco de uma só vez, você quebra o monólito. Se não sincronizar, clientes cadastrados no sistema novo não conseguem comprar no sistema legado.
A Solução para os Dados: Sincronização Assíncrona e CDC
Durante a fase de transição, a integridade dos dados deve ser assegurada por técnicas como Change Data Capture (CDC) com ferramentas como Debezium ou réplicas via Kafka, ou pelo uso estratégico de um Anti-Corruption Layer (ACL). O monólito continua achando que é o dono da verdade para módulos não migrados, enquanto eventos de domínio propagam alterações para as novas bases de dados em tempo real.
Onde isso vive na arquitetura? Implementando com YARP no ecossistema .NET
Para criar a camada de interceptação do Strangler Fig de forma performática e nativa no ecossistema .NET, a melhor ferramenta hoje é o YARP (Yet Another Reverse Proxy) da Microsoft. Ele atua como o interceptador na borda, permitindo desviar rotas específicas para novos microsserviços enquanto mantém o restante do tráfego apontado para o monólito.
Veja um exemplo prático de configuração no appsettings.json:
{
"ReverseProxy": {
"Routes": {
// Rota Migrada: Pagamentos agora vai para o novo Microsserviço
"rota-pagamentos": {
"ClusterId": "cluster-pagamentos-microsservico",
"Match": {
"Path": "/api/pagamentos/{**catch-all}"
}
},
// Rota Legada (Fallback): Todo o resto ainda vai para o Monólito
"rota-monolito-fallback": {
"ClusterId": "cluster-monolito-legado",
"Match": {
"Path": "{**catch-all}"
}
}
},
"Clusters": {
"cluster-pagamentos-microsservico": {
"Destinations": {
"destino-novo": {
"Address": "https://pagamentos-api.internal.empresa.com/"
}
}
},
"cluster-monolito-legado": {
"Destinations": {
"destino-antigo": {
"Address": "https://monolito.internal.empresa.com/"
}
}
}
}
}
}
E no Program.cs da aplicação Gateway:
var builder = WebApplication.CreateBuilder(args);
// Adiciona o YARP carregando as rotas da configuração
builder.Services.AddReverseProxy()
.LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));
var app = builder.Build();
// Intercepta e roteia o tráfego de forma transparente
app.MapReverseProxy();
app.Run();
Conforme novos módulos ficam prontos (ex: Catálogo, Checkout, Inventário), basta adicionar uma nova regra de rota apontando para o respectivo cluster. O monólito é "estrangulado" gradualmente sem nenhum minuto de indisponibilidade.
As Três Regras de Ouro do Strangler Fig
- Comece pelas Extremidades (Menor Acoplamento): Não tente migrar o núcleo de faturamento na semana um. Comece por funcionalidades periféricas, serviços de notificação, rotas somente de leitura (Read-Only) ou áreas de autenticação. Isso valida a esteira de CI/CD, a infraestrutura de contêineres e a governança antes de tocar no coração do sistema.
- Evite o Banco de Dados Compartilhado: A tentação de plugar o microsserviço novo no banco Oracle/SQL Server antigo do monólito é enorme. Resista. Banco compartilhado amarra os esquemas e impede que o microsserviço evolua independentemente.
- Comemore a Exclusão de Código: O padrão só termina quando o código velho é fisicamente deletado do monólito. Marque cerimônias de time para deletar rotas legadas e desligar tabelas antigas. Isso previne que o monólito se torne um "zumbi" eterno sustentado pela operação.
Conclusão
Modernização de arquitetura não é uma corrida de 100 metros com linha de chegada mágica; é uma maratona de gestão de risco e consistência. O Padrão Strangler Fig permite que você transforme um monólito assustador em uma arquitetura moderna, escalável e sustentável sem colocar o negócio em risco ou congelar as entregas de produto.
Maturidade de engenharia de software não se demonstra dizendo o quanto você odeia o sistema legado, mas sim pela habilidade cirúrgica de substituí-lo em pleno voo.