Hva er database-per-service-prinsippet?

Question

Accepted Answer

**Database per service** betyr at hver mikrotjeneste eier sin egen private database, og ingen annen tjeneste får lese eller skrive til den direkte. Andre tjenester må gå gjennom API-en til den som eier databasen.

## Hvordan det fungerer

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

Hvis Orders trenger brukerdata, kaller den Users API — den spør **ikke** `usersDB` direkte.

## Hvorfor håndheve det

- **Løs sammenkobling** — en tjeneste kan endre databaseskjemaet sitt fritt.
- **Uavhengig distribusjon** — ingen delt-skjema migrasjoner på tvers av team.
- **Teknologivalg** — en tjeneste bruker Postgres, en annen MongoDB.

## Kostnaden

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

## Fallgruppe

En **delt database** er det klassiske anti-mønsteret — det binder tjenestene sammen i det skjulte slik at de ikke lenger kan distribueres uavhengig.

## Hvorfor det betyr noe

Private databaser er det som faktisk gjør tjenester uavhengige; del en database og du har en distribuert monolitt.

Preisen er at joins og transaksjoner nå spenner over tjenester, noe som tvinger mønstre som sagas og eventual consistency — en bevisst avveiing for autonomi.