Qu'est-ce que le principe "database per service" ?

Question

Accepted Answer

**Database per service** signifie que chaque microservice possède sa propre base de données privée, et aucun autre service ne peut la lire ou y écrire directement. Les autres services doivent passer par l'API du service propriétaire.

## Pourquoi c'est important

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

Si Orders a besoin de données utilisateur, il appelle l'API Users — il ne requête **pas** `usersDB` directement.

## Pourquoi l'appliquer

- **Couplage faible** — un service peut modifier son schéma librement.
- **Déploiement indépendant** — pas de migrations de schéma partagé entre les équipes.
- **Choix technologique** — un service utilise Postgres, un autre MongoDB.

## Le coût

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

## Piège

Une **base de données partagée** est l'anti-pattern classique — elle couple silencieusement les services de sorte qu'ils ne peuvent plus être déployés indépendamment.

## Pourquoi c'est important

Les bases de données privées sont ce qui rend réellement les services indépendants ; partager une base de données et vous avez un monolithe distribué.

Le prix est que les jointures et les transactions s'étendent maintenant sur plusieurs services, ce qui impose des patterns comme les sagas et la cohérence finale — un compromis délibéré pour l'autonomie.