Qu'est-ce qu'une architecture orientée événements dans les microservices ?

Question

Accepted Answer

Dans une **architecture orientée événements**, les services communiquent en **produisant et consommant des événements** via un broker (Kafka, RabbitMQ, etc.). Un service annonce qu'quelque chose s'est produit ; les services intéressés réagissent — le producteur ne connaît pas ces consommateurs et n'attend pas leur réponse.

## Comment ça fonctionne

```text
Order Service ─publish→ [ Event Broker: "order.placed" ]
                              │
            ┌─────────────────┼──────────────────┐
            ▼                 ▼                  ▼
      Inventory         Notification          Analytics
      (reserve stock)   (send email)          (record metric)
```

## Exemple de charge utile d'événement

```json
{
  "eventType": "order.placed",
  "eventId": "e-9f2c",          // unique → consumers dedupe
  "occurredAt": "2026-06-18T10:00:00Z",
  "data": { "orderId": "42", "total": 99.5 }
}
```

## Avantages

- **Couplage faible** — ajoutez un nouveau consommateur sans modifier le producteur.
- **Résilience** — le broker met en buffer les événements pendant les pannes.
- **Scalabilité** — les consommateurs se dimensionnent indépendamment.

## Pièges

```text
⚠️ Eventual consistency — readers may briefly see stale data
⚠️ Duplicate delivery — make consumers idempotent (use eventId)
⚠️ Ordering — only guaranteed within a partition/queue
⚠️ Hard to trace a flow across many consumers
```

## Pourquoi c'est important

La conception orientée événements vous permet d'ajouter des fonctionnalités (analytics, détection de fraude, notifications) en vous abonnant simplement, sans aucune modification aux producteurs existants.

Cette extensibilité et cette résilience ont un coût : la cohérence éventuelle et un débogage plus difficile — le compromis central que vous acceptez en optant pour l'événementiel.