Comment les microservices communiquent-ils entre eux ?

Question

Accepted Answer

Les services communiquent soit de manière **synchrone** (requête/réponse via REST ou gRPC), soit de manière **asynchrone** (messages/événements via un broker comme Kafka ou RabbitMQ).

## Synchrone (requête/réponse)

L'appelant attend une réponse. Simple et intuitif, mais cela couple la disponibilité — si l'appelé est hors ligne, l'appelant en est affecté.

```http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
```

## Asynchrone (messages/événements)

L'expéditeur publie un message et continue ; les consommateurs le traitent plus tard. Cela découple les services dans le temps.

```text
Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service
```

## Quand utiliser lequel

| Besoin | Choisir |
|---|---|
| Réponse immédiate pour l'utilisateur | Synchrone |
| Découplage, mise en buffer, fan-out | Asynchrone |
| Couplage temporel fort OK | Synchrone |
| Résilience face aux défaillances en aval | Asynchrone |

## Piège

Les longues **chaînes synchrones** (A → B → C → D) multiplient la latence et la probabilité de défaillance. Préférez l'async ou l'agrégation si possible.

## Pourquoi c'est important

Le style de communication façonne la résilience du système : les appels synchrones sont faciles à raisonner mais créent un couplage d'exécution serré, tandis que la messagerie asynchrone gagne en découplage au prix de la cohérence éventuelle.

La plupart des systèmes réels mélangent les deux — sync pour les lectures orientées utilisateur, async pour les flux de travail en arrière-plan.

Besoin	Choisir
Réponse immédiate pour l'utilisateur	Synchrone
Découplage, mise en buffer, fan-out	Asynchrone
Couplage temporel fort OK	Synchrone
Résilience face aux défaillances en aval	Asynchrone