Bagaimana anda memigrasikan monolith ke microservices menggunakan pola strangler-fig?

Question

Accepted Answer

**Pola strangler-fig** berhijrah secara bertahap: anda membungkus monolith dengan lapisan perutean, mengekstrak satu kemampuan pada satu waktu ke dalam layanan, dan mengalihkan lalu lintas ke layanan tersebut — hingga monolith "dicekik" menghilang. **Tidak ada penulisan ulang big-bang**.

## Cara kerjanya

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

## Memilih apa yang harus diekstrak terlebih dahulu

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

## Menangani data bersama

Bagian yang sulit adalah basis data. Ekstrak tabel layanan, kemudian putuskan ikatan DB bersama menggunakan acara atau lapisan anti-korupsi, sering kali melalui teknik **branch-by-abstraction** saat kedua-duanya berjalan.

## Tukar-menukar

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

## Mengapa hal ini penting

Penulisan ulang big-bang terkenal karena kegagalan — mereka membekukan pekerjaan fitur selama berbulan-bulan dan mengirimkan cutover yang berisiko sekaligus.

Pola strangler-fig membuat sistem tetap aktif dan dapat dirilis setiap saat, memungkinkan anda untuk berhenti atau memprioritaskan ulang kapan saja, dan memaksa anda menemukan batas layanan nyata dari sistem yang sedang berjalan daripada menebak-nebaknya di muka.