Bagaimana Anda melakukan migrasi monolith ke microservices menggunakan pola strangler-fig?

Question

Accepted Answer

**Pola strangler-fig** melakukan migrasi secara bertahap: Anda membungkus monolith dengan lapisan routing, mengekstrak satu kemampuan pada suatu waktu ke dalam service, dan mengalihkan traffic ke sana — sampai monolith "dicekik". Tidak ada **big-bang rewrite**.

## 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 akan 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 database. Ekstrak tabel service, kemudian putus keterkaitan shared-DB menggunakan events atau anti-corruption layer, sering kali melalui teknik **branch-by-abstraction** saat keduanya berjalan.

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

## Mengapa ini penting

Big-bang rewrite terkenal gagal — mereka membekukan pekerjaan fitur selama berbulan-bulan dan mengirimkan cutover all-at-once yang berisiko.

Strangler-fig menjaga sistem tetap hidup dan releasable sepanjang waktu, memungkinkan Anda untuk berhenti atau mengatur ulang prioritas kapan saja, dan memaksa Anda menemukan batas service yang sebenarnya dari sistem yang berjalan daripada menebaknya sejak awal.