O Mito do “Rewrite”
Todo CTO já viveu esse pesadelo: o sistema legado está lento, o time de engenharia reclama da dívida técnica e a solução proposta é: “Vamos parar tudo por 6 meses e reescrever do zero em Next.js/Go/Rust.”
Spoiler: Nunca são 6 meses. E quando (se) termina, o negócio já mudou e o novo sistema já nasce legado.
Em arquitetura de e-commerce enterprise, evolução ganha de revolução. É aqui que entra o padrão Strangler Fig (Figueira Estranguladora).
O que é o Strangler Fig Pattern?
Cunhado por Martin Fowler, a analogia vem da natureza: uma figueira que cresce ao redor de uma árvore hospedeira, gradualmente substituindo-a até que a árvore original morra e reste apenas a nova estrutura.
No e-commerce, isso significa criar uma nova aplicação (Headless/Composable) ao redor do monolito legado, interceptando rotas específicas e migrando funcionalidade por funcionalidade.
A Arquitetura da Migração
Para executar isso sem downtime, precisamos de uma peça chave: A Camada de Roteamento (Edge / Reverse Proxy).
Diagrama Lógico
graph TD
User[Usuário / Browser] --> Edge[Edge Router / CDN]
Edge -- Rota: /checkout --> Legacy[Legado Monolito]
Edge -- Rota: /minha-conta --> Legacy
Edge -- Rota: /p/* (Produto) --> NewApp[Nova App Headless (Next.js)]
Edge -- Rota: /c/* (Categoria) --> NewApp
NewApp --> CMS[Headless CMS]
NewApp --> Search[Search API]
NewApp --> CheckoutAPI[Checkout API]Passo a Passo na Vida Real
Vamos imaginar um cenário comum: Migrar um e-commerce legado (VTEX CMS Legado ou outra plataforma monolítica) para uma arquitetura Headless (FastStore/React).
Fase 1: A Fachada
Não mexa no código ainda. Coloque um CDN ou Edge Function (Cloudflare Workers, AWS CloudFront Function ou Azion) na frente do domínio. Inicialmente, ele aponta 100% do tráfego para o Legado. Downtime: Zero.
Fase 2: O Primeiro “Estrangulamento” (PDP)
A Página de Produto (PDP) geralmente é onde precisamos de mais performance e SEO.
- Desenvolvemos a nova PDP em React/Next.js.
- No Edge, criamos uma regra:
Se URL começa com /p/ -> Envia para Vercel/AWS (Novo Front).Todo o resto -> Envia para Legado.
O usuário navega na Home (Legada), clica num banner e cai na PDP (Nova). A experiência é transparente.
Fase 3: O Desafio da Autenticação (Session Sharing)
Aqui é onde a maioria dos projetos trava.
Como manter o usuário logado quando ele pula do Legado para o Novo Front?
A Solução: Compartilhamento de Cookies no mesmo domínio raiz.
O Legado deve setar o cookie de autenticação (ex: VtexIdclientAutCookie) no domínio .meusite.com. A nova aplicação lê esse cookie e valida contra a API de Identity.
War Story: Já vi projetos atrasarem meses porque o time tentou sincronizar sessões via LocalStorage ou tokens complexos no URL. Mantenha simples: Cookies HTTPOnly no domínio raiz.
Fase 4: O Fim do Monolito
Gradualmente, migramos a Home, depois a Busca, depois o Minha Conta. Quando o Legado sobrar apenas com APIs de backend (sem front), ele deixou de ser um monolito e virou um serviço.
Conclusão
Não tente engolir o elefante de uma vez. O risco operacional de uma migração Big Bang é inaceitável para operações que faturam milhões. Use o Strangler Fig para entregar valor (ex: uma PDP mais rápida) na terceira semana de projeto, não no nono mês.