Apa prinsip database-per-service?

Question

Accepted Answer

**Database per service** tegese saben microservice duwe database pribadi dhewe, lan layanan liyane ora boleh maca utawa nulis langsung. Layanan liyane kudu lucu lucu melalui API saka layanan sing duwe.

## Carane gumana

```text
┌──────────┐     ┌──────────┐     ┌──────────┐
│  Orders  │     │ Payments │     │  Users   │
│ service  │     │ service  │     │ service  │
└────┬─────┘     └────┬─────┘     └────┬─────┘
     ▼                ▼                ▼
  ordersDB        paymentsDB        usersDB   ← private, no cross-access
```

Yen Orders butuh data user, dheweke njaluk Users API — dheweke **ora** query `usersDB` langsung.

## Kenapa kudu ditegakake

- **Loose coupling** — layanan bisa ngganti schema dhewe kanthi bebas.
- **Independent deployment** — ora ana shared-schema migrations ing antarane tim.
- **Technology choice** — siji layanan nganggo Postgres, layanan liyane nganggo MongoDB.

## Biaya

```text
With no shared DB:
  ✗ no cross-service JOINs
  ✗ no single ACID transaction across services
  → need API composition, replication, or sagas instead
```

## Pitfall

A **shared database** iku anti-pattern klasik — nyepi-nyepi ngrangkep layanan supaya ora bisa deploy kanthi mandiri.

## Mengapa penting

Database pribadi kuwi sing tenan-tenan nggawe layanan mandiri; yen bareng database iku bakal dadi distributed monolith.

Harga yaiku joins lan transactions saiki nyebar ing layanan, sing meksa pola kaya sagas lan eventual consistency — trade-off sengaja kanggo autonomy.