Como você migra um monolito para microsserviços usando o padrão strangler-fig?

Question

Accepted Answer

The **strangler-fig pattern** migra incrementalmente: você envolve o monolito com uma camada de roteamento, extrai uma capacidade de cada vez em um serviço e redireciona o tráfego para ele — até que o monolito seja "estrangulado". Não há **reescrita big-bang**.

## Como funciona

```text
Step 1: route all traffic through a facade/proxy to the monolith
Step 2: extract ONE capability → new service
Step 3: route just that path to the new service
Step 4: repeat; delete that code from the monolith

Client ─▶ [ Proxy ] ─┬─▶ /orders  ─▶ NEW Orders service
                       └─▶ everything else ─▶ Monolith
```

## Escolhendo o que extrair primeiro

```text
✓ A bounded context with clear boundaries
✓ Something that needs independent scaling or deploys
✓ A part with few inbound dependencies (low risk)
✗ Don't start with the tangled core
```

## Tratando dados compartilhados

A parte difícil é o banco de dados. Extraia as tabelas do serviço e, em seguida, quebre o acoplamento do banco de dados compartilhado usando eventos ou uma camada anti-corrupção, geralmente através da técnica **branch-by-abstraction** enquanto ambos funcionam.

## Trade-offs

```text
✓ Low risk — small, reversible steps, always shippable
✓ Value early, learn the seams as you go
✗ Slow; you run a hybrid system for a long time
✗ Temporary duplication and routing complexity
```

## Por que isso importa

As reescritas big-bang comprovadamente falham — congelam o trabalho de recursos por meses e entregam uma troca all-at-once arriscada.

The strangler-fig mantém o sistema ativo e liberável o tempo todo, permite que você pare ou reprioritize em qualquer ponto e o força a descobrir limites reais de serviço a partir do sistema em execução, em vez de adivinhar antecipadamente.