Apakah monolitik terdistribusi dan anti-pola mikroservis lainnya?

Question

Accepted Answer

Hasil terburuk dari mikroservis adalah **"monolitik terdistribusi"**: layanan yang terpisah secara fisik tetapi sangat erat digandengkan sehingga harus digunakan bersama — Anda mendapatkan semua biaya distribusi dan tidak ada kemandirian.

## Tanda-tanda monolitik terdistribusi

```text
✗ Changing one service forces redeploying several others
✗ Services share a database / shared schema
✗ A single request fans out through many synchronous hops
✗ Releases must be coordinated across teams
→ you pay network + ops cost but lost independent deployability
```

## Anti-pola umum lainnya

| Anti-pola | Masalah |
|---|---|
| Shared database | Menggandenkan kembali layanan; tidak dapat mengubah skema secara independen |
| Chatty services | Banyak panggilan sinkron per permintaan → latensi, kerapuhan |
| Nano-services | Terlalu halus; overhead melampaui logika |
| No API versioning | Satu perubahan memecahkan setiap konsumen |
| Synchronous chains | Latensi dan kegagalan berlipat ganda di sepanjang A→B→C→D |
| God service | Satu layanan yang semua orang andalkan (monolitik baru) |

## Akar penyebab

Biasanya **batas yang salah**. Layanan yang dibagi berdasarkan lapisan teknis atau entitas (bukan kemampuan bisnis) berakhir dengan banyak chat dan saling ketergantungan.

```text
bad:  User-svc, Product-svc, Cart-svc all called for one checkout
good: Checkout owns the capability end to end
```

## Mengapa ini penting

Monolitik terdistribusi secara ketat lebih buruk daripada monolitik nyata — lebih lambat, lebih sulit di-debug, lebih banyak untuk dioperasikan, namun tetap tidak dapat digunakan secara independen.

Sebagian besar anti-pola dapat dilacak kembali ke batas dan basis data bersama, jadi mendapatkan konteks terbatas dan kepemilikan data yang tepat adalah apa yang membedakan mikroservis yang membantu dari yang merugikan.

Anti-pola	Masalah
Shared database	Menggandenkan kembali layanan; tidak dapat mengubah skema secara independen
Chatty services	Banyak panggilan sinkron per permintaan → latensi, kerapuhan
Nano-services	Terlalu halus; overhead melampaui logika
No API versioning	Satu perubahan memecahkan setiap konsumen
Synchronous chains	Latensi dan kegagalan berlipat ganda di sepanjang A→B→C→D
God service	Satu layanan yang semua orang andalkan (monolitik baru)