Banco de dados legado? Como adotar o padrão Strangler Fig

O desafio de mexer em um banco de dados legado gigante

Toda empresa que cresce acumula sistemas antigos, conhecidos popularmente como monólitos. Nesses sistemas, um único banco de dados guarda o segredo de funcionamento de todo o negócio, misturando tabelas de clientes, pagamentos e estoque em uma teia complexa de dependências. Na prática, isso significa que alterar uma simples coluna pode derrubar a aplicação inteira, gerando medo e paralisia na equipe de desenvolvimento.

Quando a arquitetura precisa evoluir para microsserviços, que são pequenos serviços independentes focados em tarefas específicas, a base de dados monolítica torna-se o maior obstáculo. Tentar reescrever tudo de uma só vez é um erro histórico que costuma falhar por exigir tempo excessivo e interromper a entrega de valor ao cliente. É justamente nesse cenário crítico que surge a necessidade de uma estratégia incremental, permitindo modernizar o ambiente sem parar a operação.

O que é o padrão Strangler Fig e como ele funciona na prática

O conceito do Strangler Fig vem da natureza: a figueira estranguladora é uma planta que sementes nas copas de árvores altas, cresce abraçando o tronco e enviando raízes ao solo até que a árvore original morre e a figueira ocupa o seu lugar. Na engenharia de software, a ideia é idêntica. Em vez de destruir o sistema antigo, construímos uma nova estrutura ao redor dele, substituindo funcionalidades aos poucos.

Aplicando esse conceito aos bancos de dados, você não migra todas as tabelas em um final de semana. Você escolhe um domínio isolado, como o cadastro de clientes, e cria um novo microsserviço com seu próprio banco de dados otimizado. Como vimos ao estruturar refatorações em código legado confuso e refatoração incremental, a segurança reside em passos curtos, validados e contínuos que protegem a integridade do sistema.

Estratégias de sincronização com replicação dual de dados

Durante a transição, a aplicação nova e a antiga precisam conviver e enxergar os mesmos dados. O maior desafio técnico dessa fase é a sincronização. Se um cliente atualiza o endereço na interface nova, essa alteração precisa refletir imediatamente no banco de dados legado, caso contrário outras partes da empresa que dependem do sistema antigo quebrarão.

Uma abordagem comum para resolver esse impasse é a replicação dual, onde a aplicação escreve tanto no banco antigo quanto no novo durante um período de transição. Contudo, escrever em dois lugares diferentes abre margem para falhas de consistência quando uma das operações falha. Para mitigar esse risco de gargalos operacionais e garantir estabilidade, muitos engenheiros combinam essa abordagem com técnicas de resiliência semelhantes às aplicadas ao gerenciar falhas de rede e resolver instabilidades de API no Node.js com circuit breaker.

Como usar o padrão Outbox para garantir consistência transacional

Quando duas bases de dados precisam ser mantidas em sincronia, transações distribuídas baseadas em protocolo de confirmação em duas fases costumam ser lentas e propensas a travamentos. Uma alternativa elegante e muito adotada em arquiteturas modernas é o padrão Transactional Outbox, que utiliza uma tabela auxiliar no banco de dados para registrar eventos de mudança.

Na prática, quando uma linha é inserida ou modificada no banco legado, a aplicação grava um evento correspondente em uma tabela de saída (outbox) dentro da mesma transação do banco. Um processo secundário, chamado de publisher, lê essa tabela de saída e dispara as mensagens para um barramento de eventos ou diretamente para o novo microsserviço. Isso garante que nenhum dado se perca, mesmo se a rede falhar momentaneamente ou o microsserviço estiver indisponível.

Roteamento inteligente de tráfego entre o monolito e o microsserviço

Com os dados sincronizados, o próximo passo é decidir quem atende cada requisição dos usuários. O roteamento de tráfego atua como um porteiro inteligente na porta de entrada da aplicação, geralmente implementado por meio de um API Gateway ou de regras configuradas em um proxy reverso como Nginx ou Caddy.

No início, cem por cento das chamadas de leitura e escrita vão para o monólito. Conforme o novo microsserviço ganha maturidade e estabilidade em produção, o roteamento começa a direcionar porcentagens pequenas do tráfego para a nova API — por exemplo, dez por cento dos usuários passam a usar o novo serviço de perfil. Se ocorrer qualquer comportamento anômalo ou lentidão severa comparável aos problemas descritos em como achar gargalos de IOPS de disco no Linux, o tráfego pode ser revertido instantaneamente para o monolito sem impacto perceptível.

Identificando e removendo código e tabelas órfãs com segurança

O ciclo do Strangler Fig só se completa quando o código e as tabelas antigas são totalmente apagados do monólito. No entanto, o medo de que alguma funcionalidade oculta ainda dependa daquela estrutura legada paralisa muitos desenvolvedores na hora da limpeza final.

Para realizar essa faxina com segurança, utilize logs de auditoria e métricas de acesso ao banco de dados para rastrear se alguma query ainda toca nas tabelas legadas. Monitore o comportamento do sistema por várias semanas de operação normal antes de executar a exclusão definitiva. Essa disciplina evita surpresas desagradáveis em produção e consolida a independência do novo microsserviço.

Considerações finais sobre a migração incremental de bases de dados

Adotar o padrão Strangler Fig exige paciência, planejamento rigoroso e maturidade cultural da equipe de engenharia. A migração deixa de ser um evento estressante de migração em massa e passa a ser uma evolução contínua da arquitetura. Ao desacoplar bases de dados de forma gradual, sua empresa ganha velocidade de entrega, resiliência operacional e liberdade para escalar serviços de forma independente conforme a demanda do negócio.