Quand NE DEVRIEZ-VOUS PAS utiliser les microservices ?

Question

Accepted Answer

Les microservices sont souvent le **mauvais** choix initial. Une règle courante est **« monolithe d'abord »** : commencez par un monolithe bien structuré et n'extrayez des services que lorsque vous avez une raison concrète.

## Évitez les microservices quand

```text
✗ Small team — more services than people to run them
✗ Early-stage product — domain boundaries still shifting
✗ No CI/CD, monitoring, or tracing in place
✗ Low traffic — no real scaling pressure
✗ Simple domain — splitting adds cost, not value
```

## Le coût du fractionnement prématuré

Déplacer un appel de méthode en processus vers un appel réseau ajoute de la latence, des modes de défaillance, de la sérialisation et une unité de déploiement. Si les limites sont incorrectes, vous payez tout cela **et** devez toujours refactoriser entre les services.

```text
method call        →  microseconds, can't fail
network call       →  milliseconds, can time out, can be down
```

## Meilleure approche

```text
Start: modular monolith (clear internal boundaries)
  └─▶ Extract a service ONLY when:
         · it needs independent scaling, OR
         · a separate team needs independent deploys, OR
         · it needs a different tech/SLA
```

## Pourquoi c'est important

La plupart des équipes qui adoptent les microservices trop tôt finissent par être plus lentes, non plus rapides, car elles assument les frais généraux des systèmes distribués avant d'en avoir besoin.

Conserver les limites dans un monolithe d'abord vous permet d'apprendre le domaine à bon marché et de scinder selon les bonnes coutures plus tard.