Qu'est-ce que le monolithe distribué et les autres anti-patterns de microservices ?

Question

Accepted Answer

Le pire résultat des microservices est un **« monolithe distribué »** : des services physiquement séparés mais tellement étroitement couplés qu'ils doivent être déployés ensemble — vous subissez tous les coûts de la distribution sans aucun des avantages de l'indépendance.

## Signes d'un monolithe distribué

```text
✗ Changing one service forces redeploying several others
✗ Services share a database / shared schema
✗ A single request fans out through many synchronous hops
✗ Releases must be coordinated across teams
→ you pay network + ops cost but lost independent deployability
```

## Autres anti-patterns courants

| Anti-pattern | Problème |
|---|---|
| Base de données partagée | Relie les services ; impossible de modifier le schéma indépendamment |
| Services bavards | Nombreux appels synchrones par requête → latence, fragilité |
| Nano-services | Trop granulaire ; la surcharge dépasse la logique |
| Pas de versioning d'API | Un changement casse tous les consommateurs |
| Chaînes synchrones | La latence et les défaillances se multiplient le long de A→B→C→D |
| Service omniscient | Un service auquel tout le monde dépend (un nouveau monolithe) |

## La cause racine

Généralement des **mauvaises limites**. Les services divisés par couche technique ou entité (et non par capacité métier) finissent bavards et co-dépendants.

```text
bad:  User-svc, Product-svc, Cart-svc all called for one checkout
good: Checkout owns the capability end to end
```

## Pourquoi c'est important

Un monolithe distribué est strictement pire qu'un vrai monolithe — plus lent, plus difficile à déboguer, plus à exploiter, et pourtant toujours impossible à déployer indépendamment.

La plupart des anti-patterns remontent aux limites et à une base de données partagée, donc bien définir les bounded contexts et la propriété des données est ce qui sépare les microservices utiles de ceux qui nuisent.

Anti-pattern	Problème
Base de données partagée	Relie les services ; impossible de modifier le schéma indépendamment
Services bavards	Nombreux appels synchrones par requête → latence, fragilité
Nano-services	Trop granulaire ; la surcharge dépasse la logique
Pas de versioning d'API	Un changement casse tous les consommateurs
Chaînes synchrones	La latence et les défaillances se multiplient le long de A→B→C→D
Service omniscient	Un service auquel tout le monde dépend (un nouveau monolithe)