Jak przeprowadzić migrację monolitu do mikrousług za pomocą wzorca strangler-fig?

Question

Accepted Answer

The **strangler-fig pattern** migruje przyrostowo: owijasz monolit warstwą routingu, wyodrębniasz jedną możliwość na raz do usługi i przekierowujesz do niej ruch — aż monolit zostanie "uduszony". Nie ma **big-bang rewrite**.

## Jak to działa

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

## Wybór tego, co wyodrębniać jako pierwsze

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

## Obsługa danych wspólnych

Najtrudniejsza część to baza danych. Wyodrębnij tabele usługi, następnie przerwij sprzężenie wspólnej bazy danych za pomocą zdarzeń lub warstwy anti-corruption, często za pomocą techniki **branch-by-abstraction** podczas gdy oba działają.

## Dlaczego to ważne

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

## Dlaczego to ważne

Big-bang rewrite'y słynnie się nie udają — zamrażają prace nad funkcjami na miesiące i wdrażają ryzykowne all-at-once cutover.

The strangler-fig utrzymuje system live i releasable przez cały czas, pozwala ci zatrzymać się lub zmienić priorytet w dowolnym momencie i zmusza cię do odkrycia rzeczywistych granic usług z działającego systemu zamiast zgadywania ich z góry.