Do Monolito ao Composable: O Padrão Strangler Fig na Prática

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.

1. Desenvolvemos a nova PDP em React/Next.js.
2. 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.

📚

Biblioteca do Arquiteto

Ver Preço

Refactoring Databases

Scott Ambler

Ver Preço

Working Effectively with Legacy Code

Michael Feathers

Ver Preço

Monolith to Microservices

Sam Newman

Archie (O Bibliotecário)

CURADOR

"Eu li todos eles. A maioria é lixo. Estes aqui são os que sobraram na minha prateleira depois de 30 anos codando."

--- # English Version ---

The Myth of the “Rewrite”

Every CTO has lived this nightmare: the legacy system is slow, the engineering team complains about technical debt, and the proposed solution is: “Let’s stop everything for 6 months and rewrite it from scratch in Next.js/Go/Rust.”

Spoiler: It’s never 6 months. And when (if) it finishes, the business has already changed, and the new system is born legacy.

In enterprise e-commerce architecture, evolution beats revolution. This is where the Strangler Fig pattern comes in.

What is the Strangler Fig Pattern?

Coined by Martin Fowler, the analogy comes from nature: a fig tree that grows around a host tree, gradually replacing it until the original tree dies and only the new structure remains.

In e-commerce, this means creating a new application (Headless/Composable) around the legacy monolith, intercepting specific routes and migrating functionality by functionality.

Migration Architecture

To execute this without downtime, we need a key piece: The Routing Layer (Edge / Reverse Proxy).

Real Life Step-by-Step

Let’s imagine a common scenario: Migrating a legacy e-commerce (VTEX Legacy CMS or another monolithic platform) to a Headless architecture (FastStore/React).

Phase 1: The Facade

Don’t touch the code yet. Place a CDN or Edge Function (Cloudflare Workers, AWS CloudFront Function, or Azion) in front of the domain. Initially, it points 100% of traffic to the Legacy system. Downtime: Zero.

Phase 2: The First “Strangle” (PDP)

The Product Page (PDP) is usually where we need the most performance and SEO.

1. We develop the new PDP in React/Next.js.
2. At the Edge, we create a rule: If URL starts with /p/ -> Send to Vercel/AWS (New Front). Everything else -> Send to Legacy.

The user browses the Home (Legacy), clicks a banner, and lands on the PDP (New). The experience is seamless.

Phase 3: The Authentication Challenge (Session Sharing)

This is where most projects get stuck. How to keep the user logged in when they jump from Legacy to New Front?

The Solution: Cookie Sharing on the same root domain. The Legacy system must set the auth cookie (e.g., VtexIdclientAutCookie) on the .mysite.com domain. The new application reads this cookie and validates it against the Identity API.

War Story: I’ve seen projects delayed by months because the team tried to sync sessions via LocalStorage or complex tokens in the URL. Keep it simple: HTTPOnly Cookies on the root domain.

Phase 4: The End of the Monolith

Gradually, we migrate the Home, then Search, then My Account. When the Legacy system is left with only backend APIs (no front), it has ceased to be a monolith and become a service.

Conclusion

Don’t try to swallow the elephant whole. The operational risk of a Big Bang migration is unacceptable for operations billing millions. Use the Strangler Fig to deliver value (e.g., a faster PDP) in the third week of the project, not the ninth month.