Unajifunzaje kusambaza monolith kwa microservices kwa kutumia muundo wa strangler-fig?

Question

Accepted Answer

Muundo wa **strangler-fig** hufanya uhamiaji wa taratibu: unabandika monolith na safu ya uelekezaji, kuchimba uwezo mmoja kwa wakati ndani ya huduma, na kuelekezea trafiki kwake — hadi monolith "inapooza". Hakuna **uandishi mkubwa wa haraka**.

## Jinsi inavyofanya kazi

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

## Kuchagua nini cha kuondoa kwanza

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

## Kushughulikia data iliyoshirikiwa

Sehemu ngumu ni hifadhidata. Ondoa jedwali za huduma, kisha vunja muunganisho wa DB-iliyoshirikiwa kwa kutumia matukio au safu ya kupinga ufisadi, mara nyingi kupitia mbinu ya **branch-by-abstraction** wakati zote zinafanya kazi.

## Mabadilisho

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

## Kwa nini ni muhimu

Uandishi mkubwa unajulikana kwa kushindwa — hufanya kazi ya biashara kuwa imefungwa kwa miezi na kutuma mahitaji yenye hatari iliyounganishwa.

Muundo wa strangler-fig unaweka mfumo unaofanya kazi na unaoweza kutolewa wakati wote, kukuruhusu kusimama au kupanga upya wakati wowote, na kukuzimisha kutambua mipaka halisi ya huduma kutoka kwa mfumo unaofanya kazi badala ya kuweka mabango yao mapema.