Service Bus ou Event Hubs ?

Sur presque chaque projet Azure, la même question revient en atelier : « on met Service Bus ou Event Hubs ? ». Les deux transportent des messages. Ils ne répondent pas au même besoin.

La question à se poser

Est-ce qu’un message est une commande à traiter une fois, ou un fait à conserver et relire ?

• Une commande (« facture ce client », « envoie ce mail ») doit être traitée une fois, par un consommateur, et ne pas se perdre en cas d’échec. C’est Service Bus.
• Un fait (« le capteur a mesuré 21,4 °C », « l’utilisateur a ouvert la page ») arrive en volume, se lit par plusieurs lecteurs indépendants, et peut se relire depuis un point donné. C’est Event Hubs.

Ce que Service Bus apporte

• Des files et des topics avec abonnements filtrés par règles.
• Le verrouillage d’un message pendant son traitement, la dead-letter queue pour ce qui échoue, les messages programmés et les sessions pour garder l’ordre par client.
• Les transactions : recevoir un message et en envoyer un autre de façon atomique.

C’est l’outil des processus métier : commandes, paiements, orchestration entre services.

Ce que Event Hubs apporte

• Des partitions qui absorbent des millions d’événements par seconde.
• Une rétention : on relit l’historique en déplaçant son offset.
• Des groupes de consommateurs : la supervision, l’analytique et l’archivage lisent le même flux sans se gêner.

C’est l’outil de la télémétrie, des journaux d’activité et de l’ingestion vers une plateforme de données.

Les pièges que je vois le plus souvent

1. Event Hubs pour des commandes : pas de dead-letter, pas de verrou ; il faut tout réécrire à la main pour ne pas perdre un échec.
2. Service Bus pour de la télémétrie : le coût et le débit deviennent vite le sujet principal.
3. Une seule file pour tout : un consommateur lent bloque les autres. Un topic par famille d’événements métier, un abonnement par consommateur.

En une phrase

Si vous devez savoir qu’un message a été traité, prenez Service Bus. Si vous devez pouvoir le relire, prenez Event Hubs. Et rien n’empêche d’avoir les deux : les faits dans Event Hubs, les décisions qu’ils déclenchent dans Service Bus.