Un bus de messages est l’intermédiaire qui transporte un événement d’un composant émetteur vers un ou plusieurs composants intéressés, sans que l’émetteur sache qui les reçoit ni n’attende leur réponse. On ne le branche pas partout le premier jour. On l’introduit sur un cas qu’on maîtrise, et on apprend dessus.
Un bus de messages laisse deux composants communiquer sans que l’un attende l’autre. On le branche d’abord là où une erreur ne fait pas tomber la commande : une notification, une statistique. NATS tient en un seul binaire, ce qui en fait un terrain commode pour ce premier pas.
Ce que le bus change dans un monolithe couplé
Quand A a besoin que B fasse quelque chose, A appelle B et attend. Si B rame, A se retrouve bloqué ; si B s’effondre, A part avec lui. Le bus retourne la logique : A publie un événement (« une commande a été créée ») et continue son chemin. B s’abonne, et réagit quand il peut. Vous gagnez là deux choses. Le découplage, puisque A ne connaît plus B ni sa disponibilité. Une forme de résilience aussi, car un B momentanément en rade laisse l’événement patienter au lieu de l’envoyer à la poubelle.
Pourquoi NATS pour ce premier pas ? Il tient dans un seul binaire et démarre avec une poignée d’options : aucun service annexe à installer et maintenir à côté (là où d’autres bus comme Kafka réclamaient longtemps un cluster Zookeeper, une brique de coordination supplémentaire à faire tourner en plus), pas de demi-journée de configuration avant le premier message. La publication/abonnement et les files de travail (queue groups) qu’il offre suffisent largement au début. J’ai vu une équipe perdre trois semaines à apprivoiser Kafka pour un volume que NATS aurait absorbé sans transpirer. Le modèle événementiel, voilà ce qui compte ; le broker exact, vous en changerez plus tard si le besoin l’exige.
Le premier cas, et ce qu’il vous apprend
Je prends toujours un événement secondaire, où l’échec ne casse rien. À la création d’une commande, je publie commande.creee. Des consommateurs s’y abonnent : l’un envoie l’email de confirmation, un autre met à jour des statistiques, un troisième prévient un système tiers. Si l’email part en erreur, la commande reste enregistrée. C’est exactement le terrain où l’on veut faire ses premières bêtises.
Trois questions tombent vite sur ce cas, et mieux vaut les rencontrer ici qu’ailleurs : publier et consommer sans coller le code métier au client NATS ; gérer un consommateur qui était mort pendant l’émission, ce qui amène tôt ou tard JetStream, la couche de persistance intégrée au même binaire ; et l’idempotence, le vrai sujet. Votre consommateur recevra deux fois le même événement un jour. S’il envoie alors deux emails, c’est lui le coupable, pas le broker. Cette livraison en double surprend tout le monde la première fois : ce n’est pas un accident, c’est une situation normale dont il faut tenir compte dès la première ligne.
Un conseil pour finir : laissez ce premier cas tourner en production quelques semaines avant d’en brancher un deuxième. Vous découvrirez vos propres réflexes de supervision, de relance et de logs sur un flux dont une défaillance ne vous coûte rien. C’est cette routine acquise à bas risque, bien plus que NATS lui-même, qui rendra sûr le jour où vous y déplacerez un flux qui compte.