Architecture événementielle : penser en événements avec Kafka
Passer des appels synchrones aux événements découple les services et absorbe les pics. Les principes de l'event-driven, et le rôle du log distribué.
Dans une architecture classique, un service en appelle un autre directement (par HTTP, par exemple) et attend sa réponse. C'est simple à comprendre, mais fragile : si le service appelé est lent ou indisponible, l'appelant se bloque, et la panne se propage en cascade. L'architecture événementielle (event-driven) renverse complètement cette logique.
Du « demander » au « annoncer »
Au lieu d'appeler directement, un service publie un événement qui décrit un fait accompli : « une commande a été passée ». Les autres services y réagissent chacun à leur rythme : la facturation émet la facture, le stock se décrémente, la notification part. Point crucial : l'émetteur ignore qui l'écoute, et n'a pas besoin de le savoir.
Le producteur d'un événement ignore ses consommateurs. C'est précisément de cette ignorance que naît le découplage.
Kafka : bien plus qu'une file de messages
Apache Kafka, créé chez LinkedIn puis passé en open source à la fondation Apache, n'est pas une simple file de messages classique. C'est un log (journal) distribué, persistant et ordonné. La différence est fondamentale : dans une file traditionnelle, un message consommé disparaît. Dans Kafka, les événements restent (selon une politique de rétention), et plusieurs consommateurs indépendants peuvent les lire — et les relire — chacun à sa position. Les événements sont répartis en partitions, ce qui garantit l'ordre au sein d'une clé et permet le passage à l'échelle horizontale.
Cela confère trois propriétés décisives :
- Découplage — on branche un nouveau consommateur (analytique, cache, moteur de recherche) sans toucher au producteur.
- Rejouabilité — un service qui redémarre, ou un nouveau service, reprend la lecture là où il en était (ou depuis le début).
- Absorption des pics — Kafka encaisse les rafales d'écriture que les consommateurs traitent ensuite à leur propre rythme (effet tampon).
Le prix à payer : la cohérence éventuelle
Ce style a un coût réel : le système devient asynchrone et éventuellement cohérent. Une commande peut être « passée » une fraction de seconde avant que le stock ne soit décrémenté. Il faut concevoir avec cette réalité : garantir l'idempotence (traiter deux fois le même événement ne doit pas doubler l'effet), gérer les doublons et l'ordre (via la clé de partition), et outiller le débogage qui devient plus difficile qu'avec un simple appel synchrone.
Quand l'adopter (et quand s'abstenir)
L'événementiel brille quand plusieurs services doivent réagir au même fait, quand les charges sont irrégulières, ou quand on veut découpler des équipes qui évoluent à des rythmes différents. En revanche, pour un flux simple, linéaire et transactionnel (« je lis, je réponds »), un bon vieil appel synchrone reste souvent plus clair et plus sûr. L'événementiel n'est pas une fin en soi : c'est un outil de découplage, à sortir quand le découplage a de la valeur.