Comment migrer un monolithe vers des microservices en utilisant le pattern strangler-fig ?

Question

Accepted Answer

Le **pattern strangler-fig** effectue une migration progressive : vous enveloppez le monolithe avec une couche de routage, extrayez une capacité à la fois dans un service, et redirigez le trafic vers celui-ci — jusqu'à ce que le monolithe soit « étranglé ». Il n'y a **pas de réécriture big-bang**.

## Comment cela fonctionne

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

## Choisir ce qu'extraire en premier

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

## Gérer les données partagées

La partie difficile est la base de données. Extrayez les tables du service, puis cassez le couplage DB partagé en utilisant des événements ou une couche anti-corruption, souvent via la technique **branch-by-abstraction** pendant que les deux tournent.

## Compromis

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

## Pourquoi c'est important

Les réécritures big-bang échouent notablement — elles gèlent le travail de développement pendant des mois et livrent un basculement très risqué en une seule fois.

Le strangler-fig maintient le système actif et livrable en permanence, vous permet d'arrêter ou de reprioritiser à tout moment, et vous force à découvrir les véritables limites de services à partir du système fonctionnant plutôt que de les supposer.