Message broker

Composant intermédiaire qui reçoit, stocke et achemine des messages entre producteurs et consommateurs, leur permettant de communiquer sans dépendance directe.

En clair

Un message broker est un intermédiaire qui reçoit des messages d'émetteurs (producteurs) et les délivre à des destinataires (consommateurs). Producteur et consommateur ne se connaissent pas directement : ils ne connaissent que le broker, qui sert de point de rendez-vous entre eux. Celui-ci met les messages en file et les distribue, ce qui permet une communication asynchrone et tamponnée, où l'émission et la consommation sont dissociées dans le temps. Deux grands modèles existent : la file de messages (un message consommé par un seul destinataire, utile pour répartir du travail) et la publication/abonnement (un même message diffusé à plusieurs abonnés indépendants). Des outils comme Kafka, qui conserve un journal ordonné des messages, ou RabbitMQ, orienté file et routage, remplissent ce rôle avec des compromis différents.

Pourquoi c'est utilisé

Le broker découple les composants dans le temps et dans l'espace : le producteur peut émettre même si le consommateur est momentanément indisponible, les messages étant conservés en attendant qu'il revienne. Il absorbe les pics de trafic en tamponnant, ce qui protège un consommateur plus lent d'une submersion soudaine, permet de diffuser un même message à plusieurs consommateurs, et autorise chaque côté à évoluer ou à monter en charge indépendamment. Cette mise en tampon agit comme un amortisseur entre des composants aux rythmes différents. C'est l'épine dorsale de la communication asynchrone, et le support concret sur lequel reposent la plupart des architectures événementielles.

En mission / dans la pratique

Le consultant configure files ou topics, écrit producteurs et consommateurs, et gère les acquittements, les nouvelles tentatives et l'ordre de traitement. Il choisit aussi comment répartir la charge entre plusieurs instances d'un consommateur, par exemple via des groupes de consommation ou un partitionnement des messages. Sur les architectures distribuées des grands comptes, le broker est souvent central : de nombreux services en dépendent, ce qui en fait à la fois un atout et un point sensible à fiabiliser. Le travail inclut le dimensionnement, la gestion des messages en échec et la surveillance du retard de consommation, c'est-à-dire l'écart entre ce qui est produit et ce qui est effectivement traité.

Pièges & bonnes pratiques

Une livraison « au moins une fois » implique des consommateurs idempotents pour tolérer les doublons sans rejouer un effet déjà appliqué : c'est souvent la garantie la plus réaliste, la livraison « exactement une fois » étant difficile et coûteuse à obtenir. Surveillez l'accumulation de messages non consommés, signe d'un consommateur trop lent ou en panne, qui peut finir par saturer le broker. Gérez explicitement les messages problématiques via une file de rebut, afin qu'un message impossible à traiter ne bloque pas indéfiniment les suivants. Réfléchissez aux garanties d'ordre, qui ont un coût et limitent souvent le parallélisme, et n'en exigez que là où c'est strictement nécessaire. Évitez enfin de transporter des messages trop volumineux : privilégiez une référence vers la donnée plutôt que la donnée elle-même.

À ne pas confondre

Le broker est le transport ; l'architecture événementielle est le style qui l'emploie. À distinguer d'un appel direct d'API REST, synchrone. Il sert souvent à relier des microservices sans les coupler.

ForTeam IT à vos côtés

Vous recherchez une mission ou un consultant expert sur ce sujet ? ForTeam IT met en relation des consultants IT freelance sélectionnés avec des grands comptes, ETI et scale-ups partout en France. Consultez aussi notre grille des TJM freelance IT et nos expertises par technologie.

Rejoindre la communauté