Hur migrerar du en monolitisk arkitektur till mikrotjänster med strangler-fig-mönstret?

Question

Accepted Answer

Mönstret **strangler-fig** migrerar inkrementellt: du omsluter monoliten med ett routingskikt, extraherar en kapacitet i taget till en tjänst och dirigerar om trafiken till den — tills monoliten "stryps" bort. Det finns **ingen stor omskrivning på en gång**.

## Hur det fungerar

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

## Välja vad som ska extraheras först

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

## Hantera delad data

Den svåra delen är databasen. Extrahera tjänstens tabeller, bryt sedan den gemensamma-DB-kopplingen med hjälp av händelser eller ett anti-korruptionsskikt, ofta via **branch-by-abstraction**-tekniken medan båda kör.

## Avvägningar

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

## Varför det är viktigt

Stora omskrivningar är kända för att misslyckas — de frysning funktionsutveckling i månader och levererar en riskfylld hel-på-en-gång cutover.

Strangler-fig-mönstret håller systemet igång och släppt under hela tiden, låter dig stoppa eller ompriortera när som helst, och tvingar dig att upptäcka verkliga tjänstgränser från det system som körs snarare än att gissa dem i förväg.