Hoe migreer je een monoliet naar microservices met behulp van het strangler-fig patroon?

Question

Accepted Answer

The **strangler-fig pattern** migreert stapsgewijs: je verpakt de monoliet met een routing layer, extraheert één mogelijkheid tegelijk naar een service, en stuurt verkeer ernaar — totdat de monoliet "verstikt" is. Er is **geen big-bang rewrite**.

## Hoe het werkt

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

## Kiezen wat je eerst extraheert

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

## Omgaan met gedeelde gegevens

Het moeilijkste deel is de database. Extraheer de tabellen van de service, onderbreek vervolgens de gedeelde-DB-koppeling met behulp van events of een anti-corruption layer, vaak via de **branch-by-abstraction** techniek terwijl beide draaien.

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

## Waarom het belangrijk is

Big-bang rewrites falen beroemd — ze bevriezen feature work voor maanden en leveren een riskante all-at-once cutover op.

The strangler-fig houdt het systeem de hele tijd live en releasable, laat je op elk moment stoppen of herprioriseren, en dwingt je echte service grenzen uit het draaiende systeem te ontdekken in plaats van ze van tevoren te raden.