Kako migrirati monolith u microservices koristeći strangler-fig pattern?

Question

Accepted Answer

**strangler-fig pattern** vrši inkrementalnu migraciju: obtlačite monolith sa slojem usmjeravanja, izvucite jednu mogućnost u servis, i preusmjerite promet prema njemu — dok monolith nije "ugušen". Nema **big-bang rewrite**.

## Kako funkcionira

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

## Odabir što prvo izvuć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
```

## Rukovanje zajedničkim podacima

Teži dio je baza podataka. Izvucite tablice servisa, zatim prekucite zajedničko-DB spregu koristeći događaje ili anti-corruption sloj, često preko **branch-by-abstraction** tehnike dok oba rade.

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

## Zašto je to važno

Big-bang rewrite-ovi su poznato loši — zamrzavaju rad na značajkama mjesecima i prate rizičan all-at-once cutover.

strangler-fig drži sustav aktivnim i objavljuju cijelo vrijeme, omogućava vam da zaustavite ili preuredite u bilo kojem trenutku, i prisiljavaju vas da odkrijete prave granice servisa iz sustava koji traje umjesto da ih pogađate unaprijed.