¿Cómo migras un monolito a microservicios utilizando el patrón strangler-fig?

Question

Accepted Answer

El patrón **strangler-fig** migra de forma incremental: envuelves el monolito con una capa de enrutamiento, extraes una capacidad a la vez a un servicio y redirige el tráfico hacia él — hasta que el monolito queda "estrangulado". No hay **reescritura de gran envergadura**.

## Cómo 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
```

## Elegir qué extraer primero

```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
```

## Gestión de datos compartidos

La parte difícil es la base de datos. Extrae las tablas del servicio, luego rompe el acoplamiento de BD compartida usando eventos o una capa anti-corrupción, a menudo a través de la técnica **branch-by-abstraction** mientras ambos se ejecutan.

## Compensaciones

```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 qué es importante

Las reescrituras de gran envergadura son famosamente propensas al fracaso — congelan el trabajo de características durante meses y lanzan un cambio riesgoso de todo-a-la-vez.

El patrón strangler-fig mantiene el sistema activo y liberalizable todo el tiempo, te permite detener o replantear prioridades en cualquier momento, y te obliga a descubrir los límites reales del servicio del sistema en ejecución en lugar de adivinarlos de antemano.