Strangler fig na prática

O problema

O mercado adora transformar padrão útil em pose.

Strangler fig sofre muito com isso.

Muita gente fala como se fosse um nome elegante para:

• quebrar monolito
• criar microsservico
• modernizar legado

Mas isso fica vago demais.

Se você não explica por onde o tráfego passa, como a decisão muda e como o antigo perde relevância com segurança, o padrão vira teatro.

Modelo mental

Pense assim:

strangler fig e uma estratégia de substituicao incremental mediada por roteamento

O ponto central não e “separar serviços”.

E este:

• o fluxo entra por uma fronteira controlada
• essa fronteira decide se vai para o antigo ou para o novo
• com o tempo, mais fluxo vai para o novo
• o antigo vai sendo sufocado até sobrar pouco ou nada

O nome e menos importante do que essa mecanica.

Quebrando o problema

Comece pela fronteira, não pelo diagrama final

Muita migração começa tentando desenhar a arquitetura futura inteira.

No strangler fig, a pergunta útil e mais simples:

por onde eu consigo interceptar e redirecionar esse fluxo sem quebrar tudo?

Essa fronteira pode ser:

• gateway
• facade
• endpoint interno
• fila
• camada de aplicação que centraliza o caso de uso

Sem fronteira controlavel, o padrão perde boa parte do valor.

Mova um fluxo por vez

Você não precisa estrangular o sistema inteiro no primeiro movimento.

Escolha uma fatia pequena:

• um endpoint
• um caso de uso
• um grupo de clientes
• um tipo de evento

Isso deixa claro:

• o que esta sendo substituido
• o que ainda esta velho
• como medir sucesso

Mantenha convivio intencional entre velho e novo

Durante um tempo, os dois lados vao coexistir.

Esse período precisa ser planejado, não tolerado de qualquer jeito.

Você precisa saber:

• quem chama qual lado
• como comparar comportamento
• quando ampliar o novo
• quando bloquear o velho

Sem essa disciplina, a migração vira duplicação confusa.

Evite transformar a estratégia em desculpa para fatiar errado

Nem toda extração incremental merece virar serviço novo.

As vezes o melhor uso de strangler fig e:

• reorganizar um fluxo dentro do mesmo deploy
• criar uma facade mais limpa
• isolar comportamento antes de decidir a topologia final

O padrão serve para reduzir risco.

Não para fabricar distribuição desnecessaria.

Defina como o antigo sera aposentado

Se você só sabe criar o lado novo, mas não sabe como o antigo perde tráfego e morre, a estratégia esta pela metade.

Boa pergunta:

o que precisa ser verdade para eu cortar este fluxo do legado com segurança?

Essa resposta precisa existir desde cedo.

Exemplo simples

Imagine um monolito que faz cadastro e precificacao.

O time quer extrair precificacao.

Plano ruim:

• cria um serviço novo
• manda metade do time reescrever tudo
• espera integrar depois

Plano melhor com lógica de strangler fig:

1. cria uma facade interna para toda chamada de precificacao
2. no início, a facade aponta para a implementação antiga
3. depois, alguns fluxos passam a usar a implementação nova por tras da mesma fronteira
4. o time compara resultado, erro e latência
5. amplia aos poucos até a implementação antiga sobrar pouco
6. só no fim remove o caminho velho

Isso e menos instagramável.

Também e muito mais operável.

Erros comuns

• Tratar strangler fig como sinonimo automático de microsservico.
• Não ter uma fronteira clara de roteamento.
• Mover vários fluxos ao mesmo tempo e perder visibilidade.
• Criar lado novo sem estratégia de aposentadoria do velho.
• Usar o nome do padrão para esconder falta de critério técnico.

Como um senior pensa

Quem tem mais experiência raramente pergunta:

“Como aplico strangler fig aqui?”

Pergunta mais isto:

“Qual a menor fronteira controlavel que me permite mover esse comportamento sem apostar a empresa em um corte único?”

Esse jeito de pensar usa o padrão como ferramenta, não como fantasia de arquitetura.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você entende o mecanismo, não se decorou nome de catalogo.

Você sobe de nivel quando:

• explica o papel da fronteira de roteamento
• fala de convivencia entre velho e novo
• mostra que a migração e incremental e observável
• evita associar o padrão automaticamente a microsservicos

Uma resposta forte costuma soar assim:

“Eu usaria a lógica de strangler fig criando uma fronteira onde o fluxo pode ser redirecionado aos poucos. Assim consigo mover partes pequenas para a implementação nova, comparar comportamento, ampliar com controle e aposentar o legado sem um corte único.”

Strangler fig bom não vende revolução. Ele compra transição segura.

Quando o nome do padrão fica mais claro do que o plano de migração, a conversa piorou.