Hogyan végzed el egy monolith migrálását microservices felé a strangler-fig minta segítségével?

Question

Accepted Answer

A **strangler-fig minta** fokozatosan végzi a migrálást: körülötte tartasz a monolitot egy routing réteggel, egyszer egy képességet ki egy szolgáltatásba húzol, és a forgalmat oda irányítod át — amíg a monolitot "meg nem fojtod". Nincs **big-bang rewrite**.

## Hogyan működik

```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álassz ki, mit vonj ki először

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

## Közös adatok kezelése

A nehéz rész az adatbázis. Vonj ki a szolgáltatás táblázatait, majd bontsd meg a megosztott-DB csatolást eseményekkel vagy anti-corruption réteggel, gyakran a **branch-by-abstraction** technikával, miközben mindkettő fut.

## Kompromisszumok

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

## Miért fontos

A big-bang rewrite-ok híresek az kudarcáról — havokra fagyasztják a funkció munkáját és veszélyes all-at-once váltást szállítanak.

A strangler-fig az egész időben élő és kiadható rendszert tart, bármikor lehetővé teszi a megállást vagy újrapriorálást, és rákényszerít arra, hogy valódi szolgáltatási határokat fedezz fel a futó rendszerből, ahelyett, hogy előre eltalálnád azokat.