ADR-0006 : RabbitMQ comme transport de messages
| Statut | Accepté |
| Date | 2025-11 |
| Décideurs | Équipe de développement Edukit |
| Périmètre | Edukit-VM, Edukit-OrgService |
Contexte
Les services Edukit échangent des messages asynchrones : commandes de saga, événements de transition d’état, événement VmCredentialIssued traversant VmService → courtier → OrgService → SMTP. Pendant une séance, le volume reste modéré à l’échelle d’un établissement (milliers d’événements), mais doit être transporté de façon fiable, avec confirmation de remise, et pouvoir être partitionné pour la mise à l’échelle horizontale du provisionnement.
Le choix du transport doit tenir compte de :
- la fiabilité (confirmations côté courtier, intégration avec la boîte d’envoi, voir ADR-0005) ;
- la simplicité de déploiement (l’environnement de développement est un Docker Compose, la production un cluster K3s) ;
- la maturité de l’intégration avec Wolverine, retenu pour les sagas (voir ADR-0004) ;
- l’absence de besoin de rejeu massif de flux ou de rétention longue durée d’un journal d’événements.
Décision
Utiliser RabbitMQ comme transport AMQP pour toute la messagerie asynchrone.
- Wolverine est configuré sur RabbitMQ avec auto-provisionnement des files, routage conventionnel, confirmations de publication (
PublisherConfirmations) et suivi des confirmations activés. - Le partitionnement est prévu mais désactivé par défaut (
Wolverine:Shards:Enabled=false) : un seul processus de travail consomme toutes les commandes de saga, ce qui suffit au pilote. Le basculer àtrue(avec un nombre de partitions, par exemple 5) crée des files RabbitMQ partitionnées par empreinte de l’identifiant de saga ; Wolverine attribue chaque file à une réplique exclusive via son protocole d’élection. Une même saga atterrit toujours sur la même réplique. Ce passage à l’échelle se fait par configuration, pas par réécriture.
Conséquences
Bénéfices
- Simplicité de déploiement : RabbitMQ s’intègre directement dans le Docker Compose de développement et dans le cluster de production, sans pile lourde à opérer.
- Maturité de l’intégration Wolverine plus RabbitMQ : transport et orchestration de saga bien éprouvés ensemble.
- Fiabilité : les confirmations de publication referment la boucle commencée par la boîte d’envoi transactionnelle (livraison au moins une fois).
- Mise à l’échelle horizontale prête : partitionnement par configuration, sans toucher au code.
Coûts et limites
- Pas de rétention longue ni de rejeu massif : RabbitMQ n’est pas un journal d’événements persistant. Si le projet devait un jour ingérer des flux à très haut débit ou rejouer l’historique complet, ce choix serait à reconsidérer (Kafka redeviendrait pertinent).
- Livraison au moins une fois : impose des consommateurs idempotents (contrainte déjà portée par ADR-0004).
Alternatives écartées
- Apache Kafka : excellent pour le rejeu, la rétention longue et le très haut débit, mais surdimensionné pour Edukit (pas de besoin de rejeu massif) et plus coûteux à déployer et à opérer. La porte reste ouverte : un changement de transport est localisé dans la configuration de la messagerie.
- Azure Service Bus : courtier infogéré pertinent en environnement Azure, mais ajoute une dépendance à un service propriétaire et un coût, alors que l’objectif est un déploiement portable (Docker Compose / K3s).
- Parallélisme par files RabbitMQ pour la limitation de concurrence Proxmox : écarté au profit d’un sémaphore indexé (
ProxmoxThrottler) qui découple la limitation du transport, garantissant les mêmes limites quel que soit le partitionnement.