Parler par messages : la fiabilité des systèmes distribués

Comment plusieurs services d'un même système se parlent-ils sans tomber ensemble ? Ce cours d'architecture part des garanties, pas des technos : il explique d'abord ce qu'un message promet (et ne promet pas), puis montre comment RabbitMQ et Kafka, ses deux archétypes, tiennent ces promesses. Couplage, sémantiques de livraison, ordre et idempotence, outbox transactionnel, messages empoisonnés, backpressure, sagas : chaque chapitre ferme une faille de fiabilité ouverte par le précédent. Les exemples sont réels (Hexeract, le framework Rust de messaging) et comparés à une seconde lentille .NET (Wolverine). Fil rouge : passer une commande e-commerce, durcie chapitre après chapitre.

1. 00
   Pourquoi parler par messages

   Quand un service en appelle cinq autres pour valider une commande, un seul qui tombe fait tout échouer. Le message asynchrone change la donne : voici pourquoi, et ce qu'il promet vraiment.
   18 min
2. 01
   Les trois familles de messages

   Le chapitre précédent opposait la commande et l'événement. Mais demander une information n'est ni l'un ni l'autre. Voici la troisième famille, et la ligne nette qui les sépare toutes les trois.
   19 min
3. 02
   Courtier contre journal

   Le chapitre précédent traitait la boîte aux lettres comme une boîte noire. On l'ouvre. Il y a deux façons de la construire, et toute la différence tient à une question : qui se souvient de ce qui a déjà été lu ?
   22 min
4. 03
   Sémantiques de livraison

   Le chapitre précédent a posé un mot sans le creuser : l'acquittement. Tout se joue sur son instant. Acquitter trop tôt, c'est risquer de perdre un message ; acquitter trop tard, c'est risquer de le traiter deux fois. Il n'y a pas de troisième porte, et ce chapitre explique pourquoi.
   22 min
5. 04
   Ordre et idempotence

   Le chapitre précédent a promis un consommateur qui reconnaît un message déjà traité, sans dire comment. Le voici. Mais en le construisant, on découvre que la redélivraison ne fait pas qu'apporter des doublons : elle peut aussi tout remettre dans le désordre, et l'idempotence seule n'y suffit pas.
   24 min
6. 05
   Dual-write et outbox transactionnel

   On a blindé le consommateur au chapitre précédent. Mais tout reposait sur une promesse du producteur : publier le message quand l'état métier change. Or publier, c'est toucher deux mondes à la fois, sa base et le broker, et rien ne les rend atomiques ensemble. Ce chapitre répare cette dernière faille.
   25 min