Hvad er database-per-service-princippet?

Question

Accepted Answer

**Database per service** betyder, at hver microservice ejer sin egen private database, og ingen anden service må læse fra eller skrive til den direkte. Andre services skal kommunikere gennem den ejende services API.

## Hvordan det fungerer

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

Hvis Orders har brug for brugerdata, kalder den Users API — den **forespørger ikke** direkte i `usersDB`.

## Hvorfor skal det håndhæves

- **Loose coupling** — en service kan ændre sit skema frit.
- **Independent deployment** — ingen delte migrations af skema på tværs af teams.
- **Technology choice** — en service bruger Postgres, en anden MongoDB.

## Prisen

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

## Fælde

En **delt database** er det klassiske anti-pattern — det stilfærdig forbinder services, så de ikke længere kan deployes uafhængigt.

## Hvorfor det betyder noget

Private databaser er det, der faktisk gør services uafhængige; del en database, og du har en distribueret monolitisk system.