Apa itu monolith terdistribusi dan anti-pattern microservices lainnya?

Question

Accepted Answer

Hasil terburuk dari microservices adalah **"monolith terdistribusi"**: layanan yang terpisah secara fisik tetapi begitu tightly coupled harus diterapkan bersama — Anda mendapatkan semua biaya distribusi tanpa kemandirian apa pun.

## Tanda-tanda monolith 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-pattern umum lainnya

| Anti-pattern | Masalah |
|---|---|
| Database bersama | Menghubungkan kembali layanan; tidak ada perubahan schema independen |
| Layanan cerewet | Banyak panggilan sync per permintaan → latency, fragilitas |
| Nano-services | Terlalu fine-grained; overhead mengalahkan logika |
| Tanpa versioning API | Satu perubahan merusak setiap konsumen |
| Rantai synchronous | Latency dan kegagalan berlipat ganda sepanjang A→B→C→D |
| Layanan Dewa | Satu layanan yang semua orang bergantung pada (monolith baru) |

## Akar penyebab

Biasanya **batas yang salah**. Layanan yang dibagi oleh lapisan teknis atau entitas (bukan kemampuan bisnis) berakhir cerewet dan saling bergantung.

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

## Mengapa ini penting

Monolith terdistribusi secara ketat lebih buruk daripada monolith nyata — lebih lambat, lebih sulit di-debug, lebih banyak untuk dioperasikan, namun masih tidak mungkin untuk diterapkan secara independen.

Sebagian besar anti-pattern dapat dilacak kembali ke batas dan database bersama, jadi mendapatkan bounded contexts dan kepemilikan data dengan benar adalah yang membedakan microservices yang membantu dari yang merugikan.

Anti-pattern	Masalah
Database bersama	Menghubungkan kembali layanan; tidak ada perubahan schema independen
Layanan cerewet	Banyak panggilan sync per permintaan → latency, fragilitas
Nano-services	Terlalu fine-grained; overhead mengalahkan logika
Tanpa versioning API	Satu perubahan merusak setiap konsumen
Rantai synchronous	Latency dan kegagalan berlipat ganda sepanjang A→B→C→D
Layanan Dewa	Satu layanan yang semua orang bergantung pada (monolith baru)