Cum migrezi un monolit la microservicii folosind modelul strangler-fig?

Question

Accepted Answer

The **strangler-fig pattern** migrează incremental: înfășori monolitul cu un strat de rutare, extragi o capabilitate pe rând într-un serviciu și redirecționezi traficul către el — până când monolitul este "strangulat". Nu există **big-bang rewrite**.

## Cum funcționează

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

## Alegerea ce să extragi mai întâi

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

## Gestionarea datelor partajate

Parte dificilă este baza de date. Extrage tabelele serviciului, apoi întrerupe cuplarea bazei de date partajate folosind evenimente sau un strat anti-corupție, adesea prin tehnica **branch-by-abstraction** în timp ce ambele rulează.

## Compromisuri

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

## De ce conteaza

Big-bang rewriteurile eșuează în mod notabil — înghață lucrul la funcții pentru luni și livrează o trecere all-at-once riscantă.

The strangler-fig menține sistemul live și lansat tot timpul, te permite să te oprești sau să reprioitizezi în orice moment și te forțează să descoperi limitele reale ale serviciilor din sistemul activ în loc să le ghicești dinainte.