Architecture événementielle
Dans une architecture événementielle, les composants d'un système communiquent en publiant et en écoutant des événements (« commande créée », « paiement validé ») plutôt qu'en s'appelant directement les uns les autres. Chaque service peut évoluer, tomber en panne ou être remplacé sans bloquer les autres.
C'est un pattern fréquent sur les plateformes SaaS qui doivent connecter plusieurs services tiers : quand une commande est créée, un événement peut déclencher en parallèle l'envoi d'un email de confirmation, la mise à jour du stock et l'appel au prestataire de paiement, sans que ces trois actions dépendent les unes des autres. Cela facilite aussi l'absorption des pics de trafic, chaque événement pouvant être traité dès que la capacité est disponible plutôt que de bloquer l'utilisateur en attendant que tout se termine.
Le principal risque est la complexité de débogage : quand une action déclenche une chaîne d'événements répartis sur plusieurs services, retracer ce qui s'est passé en cas d'erreur devient difficile sans outillage adapté (traçabilité, monitoring, gestion des événements en échec). Il vaut mieux réserver ce pattern aux systèmes qui ont réellement besoin de ce découplage, et prévoir dès le départ la façon dont on va observer et déboguer les flux d'événements.
