Estrangulando um monolito sem parar o negócio

Todo time que convive com um monolito em degradação já ouviu a frase “vamos reescrever do zero”. É tentadora: um projeto limpo, tecnologias novas, sem dívida. Mas o negócio não para enquanto você reescreve — e é aí que mora o risco.

Quando assumi o time de ERP, a aplicação sofria com lentidão e indisponibilidade justamente nos momentos de pico. A decisão foi outra: estrangular o monolito aos poucos, substituindo partes dele por serviços novos até que o antigo deixasse de ser necessário.

Por que estrangular, e não reescrever

O padrão Strangler Fig troca um grande salto por muitos passos pequenos e reversíveis. Cada passo entrega valor e reduz risco:

• o sistema antigo continua atendendo enquanto o novo amadurece;
• cada fatia migrada pode voltar atrás com uma mudança de rota;
• o time aprende o domínio de verdade antes de redesenhar tudo.

Comece pela borda

O primeiro passo foi colocar uma camada de roteamento na frente do monolito. A partir dela, cada rota pode apontar para o código antigo ou para o serviço novo, sem que o cliente perceba:

spring:
cloud:
  gateway:
    routes:
      - id: pedidos-novo
        uri: http://pedidos-service
        predicates:
          - Path=/api/pedidos/**
      - id: legado
        uri: http://erp-monolito
        predicates:
          - Path=/**

Dados: a parte difícil

Separar código é a parte fácil. O desafio real é o banco compartilhado: tabelas que todo mundo lê e escreve. Funcionou melhor tratar cada serviço novo como dono de seus dados, sincronizando com o legado por eventos durante a transição.

Migração sem dono de dados é só um monolito distribuído — mais lento e mais difícil de depurar.

O que eu faria diferente

Investiria em observabilidade antes da primeira rota migrada. Sem métricas comparáveis entre o caminho antigo e o novo, cada discussão sobre performance vira opinião. E envolveria o time de produto desde o início: cada fatia migrada é também uma chance de corrigir fluxos que ninguém mais questionava.

No fim, o maior ganho não foi tecnológico. Foi o time ganhar confiança para mudar o sistema sem medo — e isso escala muito melhor que qualquer arquitetura.