Les architectures événementielles ou « Event Driven Architecture », plus modulaires et basées sur la collaboration de composants unitaires faiblement couplés, permettent de répondre à ces exigences.
Pour l’implémentation de ce type d’architecture, il existe divers patterns et modèles à considérer en fonction des cas d’usage spécifiques et des exigences particulières.
Ainsi il conviendra de choisir en fonction des cas d’usage entre orchestration et chorégraphie de services, entre des échanges synchrones ou asynchrones.
Le modèle de consommation des données est également un point critique à prendre en compte. Pour chaque ensemble de données, nous avons en effet la possibilité d’opter pour un modèle centralisé ou décentralisé basé sur la réplication.
Dans cet article, nous détaillerons dans un premier temps les principes des architectures événementielles ainsi que ses principales caractéristiques. Dans un second temps nous discuterons des différents patterns pouvant être utilisés en fonction des cas d’usage.
Architecture événementielle : vers un nouveau modèle d’architecture pour répondre aux problématiques d’aujourd’hui
Dans un contexte globalisé et concurrentiel, les systèmes d’information doivent pouvoir évoluer rapidement pour être capable de réagir aux changements du marché.
La réduction du Time to Market devient un impératif pour répondre rapidement aux offres concurrentes. Elle permet ainsi de proposer de nouveaux services et de s’adapter à des évolutions de plus en plus rapides de l’écosystème.
Dès lors, pour répondre à ce besoin, l’agilité et l’évolutivité du système d’information sont déterminants.[1]
Par ailleurs, les applications sont de plus en plus distribuées et connectées. Elles doivent pouvoir supporter des pics de charge importants et être disponibles 24 / 24, 7 jours sur 7.
Les architectures événementielles apportent une réponse pertinente à ces problématiques. Une étude menée par l’institut IDC[2] sur un panel de 300 entreprises de plus 1000 salariés, révèle que 47 % des entreprises interrogées utilisent déjà ce modèle d’architecture pour divers cas d’usage.
Figure 1 – Statistiques d’utilisation des architectures événementielles sur un panel de 300 entreprises de plus de 1000 salariés
Cette même étude démontre que parmi les entreprises ayant adopté ces architectures, plus de 85 % considèrent avoir atteint, voire dépassé, leurs objectifs en termes de ROI.
Figure 2 – Evaluation des objectifs en termes de ROI liés à l’usage des architectures événementielles
Figure 3 – Principaux gains apportés par l’usage des architectures événementielles
Les architectures événementielles se présentent ainsi comme un atout majeur pour les entreprises désireuses de prospérer dans un environnement en constante évolution.
Mais qu’est-ce qui différencie ce modèle des approches traditionnelles et en fait une option si attractive pour les entreprises d’aujourd’hui ? Pour en juger, découvrons d’abord ses principes fondamentaux.
Architecture événementielle : Une réactivité optimale face aux défis d’aujourd’hui
Une architecture réactive réagissant en temps réel à des événements
Une architecture événementielle ou « Event Driven Architecture » est avant tout un système réactif[3] capable de réagir en temps réel à des événements. L’architecture repose sur des composants indépendants et faiblement couplés.
Dans ce modèle, les différents composants ne sont pas liés de manière fortement couplée. Ces derniers communiquent en émettant et en consommant des événements.
Par conséquent, ils peuvent être développés, testés et déployés de manière indépendante, sans affecter les autres composants. Cela rend ainsi le système plus souple et plus agile.
Principes d’une architecture événementielle
Pour une architecture événementielle performante, priorité à la modularité, la disponibilité, la résilience et à l’indépendance des composants. Voyons ensemble les principes qui en régissent son fonctionnement. Une architecture événementielle doit être :
- Disponible : le système doit continuer à fonctionner en cas d’incident impactant un composant. Chaque composant doit donc être multi instancié afin de permettre une tolérance aux pannes.
- Scalable: le système est capable de supporter une montée en charge importante sans impact majeur sur l’architecture.
- Résiliente: le système est capable de réagir à un incident afin de rester disponible et de s’auto réparer pour revenir automatiquement à sa capacité nominale.
- Basée sur des composants indépendants et faiblement couplés: Le système est conçu de manière modulaire sous la forme de composants indépendant. Les communications asynchrones basées sur des messages ou des notifications doivent être privilégiées lorsque cela est possible. Les communications asynchrones permettent un couplage lâche entre les composants.
- Orientée message: les composants du système communiquent de manière asynchrone en utilisant des événements. Chaque composant réagi en temps réel aux événements qu’il reçoit ou auxquels il est abonné.
Producteurs, Gestionnaires, Consommateurs : Les Piliers d’une Architecture Réactive
Une architecture événementielle repose sur une structure fondamentale composée de trois types de composants essentiels pour son bon fonctionnement : les producteurs d’événements, les gestionnaires d’événements et les consommateurs d’événements. Ces acteurs jouent un rôle crucial dans la dynamique réactive de ce système.
Les producteurs émettent généralement des messages afin de notifier d’un changement d’état du système ou de déclencher l’exécution d’un traitement ou d’un processus.
Les gestionnaires d’événements reçoivent les messages des producteurs et les diffusent aux consommateurs concernés selon différents patterns.
Enfin, les consommateurs d’événements traitent les messages reçus et effectuent les actions appropriées.
Figure 4 – Composants d’une architecture événementielle
Des traitements synchrones et asynchrones distribués sur un ensemble de services
Deux modes de communication peuvent être utilisés dans une architecture événementielle :
- Un mode synchrone par appel d’une API exposée par un composant
- Un mode asynchrone par envoi d’un évènement sur un Topic ou d’un message dans une file de messages à destination d’un consommateur d’événement identifié.
Le traitement d’un événement s’apparente à un workflow plus ou moins complexe combinant des appels d’API, des envois de messages et des publications d’événements.
Les API sont un moyen d’exposer un point d’entrée permettant l’exécution d’une fonction métier. Ce mode d’exposition permettant d’exposer les fonctions métier en interne mais également à l’extérieur de l’entreprise s’inscrit tout naturellement dans les architectures événementielles.
Ainsi chaque composant doit exposer les API permettant d’interagir avec lui. Cette interface doit être claire, stable et bien documentée. Chaque modification de l’interface doit donner lieu à une nouvelle version.
L’envoi de messages ainsi que la publication d’événements sont des moyens permettant de déclencher des traitements asynchrones non bloquant pour le traitement principal.
Une meilleure collaboration avec le monde extérieur
De par sa nature, une architecture événementielle est conçue pour réagir à des événements. Ces derniers pouvant être d’origine interne ou externe. Ce type d’architecture s’intègre donc très facilement dans un écosystème ouvert. Il permet d’interagir naturellement avec des systèmes ou des acteurs externes.
Les interactions peuvent s’effectuer selon deux modes :
- Par appels d’API exposées au monde extérieur. On parle d’API externes par opposition aux API internes réservées aux appels entre composants du système.
- Par réception et ou envoi d’événements par le biais de files de messages ou par streaming d’événements.
Figure 6 – Collaboration avec les systèmes externes
Un traitement temps réel des événements pour une expérience client optimale
Dans une architecture événementielle, les événements sont traités unitairement et en temps réel contrairement à une architecture orientée batch ou les événements sont traités par lots en différé.
Prenons l’exemple d’une demande de création d’un compte d’accès à une application de banque en ligne.
Dans une architecture événementielle, le compte d’accès sera immédiatement créé. Il sera dès lors possible de se connecter immédiatement après avoir effectué la demande de création du compte.
Dans une architecture traditionnelle orienté batch, la création du compte ne sera effectuée qu’en fin de journée lors de l’exécution du batch de traitement des demandes de création de compte. En tant que client, vous devrez attendre le lendemain pour pourvoir vous connecter.
Le traitement temps réel des événements permet par ailleurs d’avoir exactement la même vision quelque que soit le canal d’accès. Ainsi une demande ou une modification effectuée par le biais d’un centre d’appel, d’un mobile ou d’une interface web sera immédiatement visible quel que soit le canal d’accès à l’information.
Architecture événementielle : Quel pattern d’architecture choisir pour quel cas d’usage
L’implémentation d’une architecture événementielle peut prendre plusieurs formes selon les choix d’architecture retenus. En effet plusieurs patterns peuvent être utilisés selon les exigences et les objectifs définis.
Comme nous l’avons vu dans le chapitre précédent, le traitement d’un événement prend la forme d’un workflow d’appels synchrones et asynchrones à un ensemble de services distribués.
Communications Synchrones vs Asynchrones
Ainsi pour chaque appel de service, la question se pose de choisir entre un appel synchrone ou asynchrone.
Communications synchrones pour une optimisation des performances et une simplification des échanges
Les appels synchrone d’API doivent être privilégiés lorsque les informations retournées peuvent être obtenus immédiatement et que ces informations sont nécessaires à la poursuite du traitement.
Par exemple, si pour exécuter un virement, il est nécessaire de s’assurer que le solde du compte est suffisant, un appel synchrone sera effectué afin de récupérer ce solde.
Cependant si une information nécessaire à la poursuite d’un processus nécessite un traitement long, un événement permettant de déclencher ce traitement sera émis. Le processus se poursuivra ensuite lors de la réception d’un événement portant le résultat du traitement.
Par exemple, lors de l’ouverture d’un compte bancaire, le compte ne sera activé qu’après réception du virement initial permettant d’alimenter le compte avec une somme minimale.
Dans le processus de création du compte, un événement sera émis afin de déclencher l’exécution du virement initial. L’activation du compte ne sera faite que lors de la réception d’un événement signifiant que ce virement a bien été exécuté.
Figure 8 – Exemple d’appel asynchrone lors de l’ouverture d’un compte bancaire
Lorsque cela est approprié, un appel synchrone permet une communication plus directe et plus simple à implémenter qu’un appel asynchrone.
Communications asynchrones pour une flexibilité et une évolutivité accrues
Les appels asynchrones sont à privilégier pour les communications entre les services d’une architecture événementielle, hormis pour des traitements instantanés nécessitant des appels synchrones.
Un appel asynchrone se matérialise généralement par l’émission d’un événement qui peut être classé en deux grandes familles :
D’une part, les événements émis afin de déclencher un traitement particulier (Pattern commande): Par exemple, pour demander l’exécution d’un virement.
D’autre part, les événements émis afin de notifier de la fin d’une étape d’un processus ou d’un changement d’état du système. Un exemple pourrait être la validation de l’exécution du virement initial lors du processus d’ouverture d’un compte bancaire.
Ces deux types d’événement correspondent aux deux cas d’usage principaux rencontrés dans les échanges asynchrones. Le premier correspond à une communication entre un émetteur d’événement et un consommateur unique; Le second à une notification pouvant être traité par plusieurs consommateurs non connus à l’avance.
Le consommateur de l’événement est connu et unique
C’est le cas lors de l’émission d’un événement de type commande permettant de demander l’exécution d’un traitement particulier. Par exemple, pour demander l’exécution d’un virement. Dans ce cas précis le consommateur de l’événement est connu et unique. On utilise en général un modèle de communication Orienté message basé sur l’utilisation de files de messages.
Le modèle orienté message peut être utilisé pour implémenter une communication asynchrone entre un producteur d’événements et un consommateur d’événements.
Plusieurs instances du producteur peuvent envoyer des messages à une file de message et plusieurs instances du consommateur peuvent écouter la file de messages. Chaque message est traité par un seul consommateur puis supprimé de la file de message.
Figure 9 – Modèle orienté message
Les consommateurs de l’événement ne sont pas connus et peuvent être multiples
C’est généralement le cas lorsqu’un événement est émis pour notifier la fin d’un sous processus ou d’un changement d’état. Par exemple la validation du panier d’achat sur un site de commerce électronique.
Plusieurs consommateurs peuvent être abonnés à cet événement. Par exemple le service en charge de l’exécution de la commande, le service en charge de la gestion des stocks, le service permettant de faire des statistiques sur les achats des consommateurs.
Dans ce cas, on utilise le modèle Publish & Subscribe. Ce modèle est utilisé lorsqu’un événement doit être traité par plusieurs consommateurs. Les événements sont publiés dans un Topic. Tous les abonnés à ce Topic sont notifiés afin de lire et traiter l’événement. Le producteur de l’événement ne connait pas les consommateurs et le nombre de consommateurs peut changer dynamiquement en fonction des abonnements à un événement donné.
Figure 10 – Modèle Publish & Subscribe
Quel modèle choisir ?
Dans les faits, les deux types d’appels, synchrones et asynchrones sont généralement utilisés dans l’implémentation d’un processus métier. Il est important d’utiliser l’un ou l’autre des modèles à bon escient.
Il est ainsi déconseillé d’utiliser systématiquement des échanges asynchrones, ce type de communication étant dans les fait plus complexe à implémenter et à monitorer.
Le bon pattern doit donc être utilisé en fonction des cas d’usage détaillés dans les paragraphes précédents.
Orchestration vs Chorégraphie de services
Les architectures événementielles basées sur la collaboration de plusieurs services indépendants sont aujourd’hui largement utilisées pour le développement des nouveaux systèmes. Il est fondamental de bien comprendre les concepts d’orchestration et de chorégraphie services. En effet, il existe des différences essentielles entre ces deux modèles architecturaux.
Le premier est un modèle centralisé appelé orchestration de services. Ce modèle est basé sur un orchestrateur qui possède la connaissance du workflow à exécuter.
Le second est un modèle décentralisé appelé chorégraphie de services, dans lequel chaque service réagi aux événements qu’il reçoit et émet lui-même des événements. Dans ce modèle, il n’y a pas de pilotage centralisé du workflow.
Qu’est-ce que l’orchestration de services ?
L’orchestration des services fait référence à une approche centralisée, où un composant central, appelé orchestrateur, est responsable de la gestion et de la coordination des interactions entre les services.
L’orchestration permet d’assurer la cohérence et la fiabilité des interactions entre les services en définissant la séquence d’étapes à suivre. Il aide également à gérer les erreurs en fournissant un point de contrôle centralisé et en garantissant que chaque service communique uniquement avec l’orchestrateur.
L’orchestration est utile dans les scénarios où une autorité centralisée est nécessaire pour contrôler les interactions entre les services, et lorsqu’il est nécessaire de coordonner et de gérer des processus complexes impliquant plusieurs services.
Qu’est-ce que la chorégraphie de services ?
La chorégraphie fait référence à l’approche décentralisée de coordination des interactions entre les services, où chaque service communique directement avec d’autres services, sans dépendre d’un coordinateur central. Dans ce modèle les interactions sont directement gérées par les services eux-mêmes.
Dans la chorégraphie, chaque service est chargé de maintenir son propre état et d’échanger des messages ou des événements avec d’autres services pour coordonner le flux de traitements. Cette approche a l’avantage de supprimer le couplage étroit entre un orchestrateur et les services qui exécutent le workflow. L’inconvénient est qu’il augmente la communication point à point entre les services.
La chorégraphie permet une plus grande évolutivité et flexibilité dans l’architecture des services, car chaque service peut évoluer et changer indépendamment, sans affecter l’ensemble du système. La chorégraphie élimine la dépendance vis-à-vis d’un orchestrateur central. De ce fait, elle permet d’augmenter la fiabilité et la résilience de l’ensemble du système.
Quel modèle choisir?
Le choix du modèle peut être induit par le modèle organisationnel de l’entreprise.
L’orchestration de service : un modèle centralisé plus rigide mais plus simple à maitriser et à monitorer
L’orchestration de services sera un modèle plus efficace dans le cas d’une organisation centralisée ayant la main sur l’ensemble du processus.
D’une manière générale, il peut être plus judicieux d’utiliser l’orchestration pour les interactions au sein d’un contexte délimité géré par une organisation centralisée.
La chorégraphie de service : un modèle décentralisé plus souple et plus évolutif mais plus complexe à maitriser et à monitorer
La chorégraphie de services peut être mieux adaptée, dans le cas d’un modèle d’organisation décentralisé impliquant des équipes au sein de différentes entités.
La chorégraphie de services peut être plus appropriée pour la collaboration entre différents systèmes. Cela favorise un couplage plus lâche entre des systèmes maintenus par des équipes différentes.
Ce modèle, plus complexe à maitriser, nécessite une plus grande maturité dans la mise en œuvre des architectures événementielles. Il nécessite également des équipes plus expérimentées dans ce type de développement.
Modèle centralisé vs modèle décentralisé des données
Dans le paragraphe précédent, nous avons détaillé les modèles centralisé et décentralisé permettant de gérer les interactions entre les services.
Dans une architecture événementielle basée sur la collaboration de services indépendants et faiblement couplés, des modèles centralisés ou décentralisés peuvent également être mis en place pour l’accès à une donnée. Chaque service est responsable de la gestion de ses données. Cependant un traitement métier a en général besoin de données gérées par différents services.
Prenons l’exemple d’une banque en ligne devant gérer des clients, des comptes à vue, des livrets d’épargne, des comptes titre, des cartes, des paiements et des virements. Chaque domaine fonctionnel, client, compte, livret d’épargne, compte titre, cartes, paiements et virement, sera géré par un service qui possédera sa propre base pour la gestion de ses données.
Figure 11 – Exemple de services métier pour la gestion d’une banque en ligne
Deux modèles sont possibles pour l’accès à ces données :
Le modèle centralisé ou chaque donnée n’est stockée que dans la base de données du service en charge de la gestion de cette donnée.
Le modèle décentralisé ou la donnée est répliquée et stockée par les différents services utilisant cette donnée.
Modèle centralisé : Avantages et inconvénients de l’accès à une donnée unique
Dans ce modèle la donnée est présente à un endroit unique. Elle est accédée via le service prenant en charge le périmètre fonctionnel incluant cette donnée. Ce service est donc dépositaire de la valeur de référence de cette donnée (Golden Source)
L’accès à la donnée en lecture s’effectue donc par appel d’une API exposée par le service en charge de traiter cette donnée. Par exemple, l’accès aux données d’un client s’effectuera par appel d’une API exposée par le service de gestion des clients.
Figure 12 – Accès à une donnée centralisé par un appel d’API synchrone
Avantages
Ce modèle garantie la cohérence de la donnée. La donnée étant stockée à un endroit unique, la valeur lue est toujours la dernière.
Inconvénients
Le service d’accès à la donnée devient donc un point de passage obligé pour y avoir accès. En cas de fort trafic, ce modèle peut poser des problèmes de scalabilité voir de latence.
Par exemple, dans le cas d’une banque en ligne, certaines données client sont nécessaires pour la gestion des opérations sur les différents type de compte. L’accès au service client devient un point de contention en cas d’augmentation du trafic. En cas d’indisponibilité totale ou partielle de ce service, c’est l’ensemble des services qui est impacté.
Figure 13 – Exemple d’appels de service pour la récupération des données client
Modèle décentralisé : Avantages et inconvénients de la réplication des données
Dans ce modèle, la donnée est répliquée dans plusieurs services. Ainsi le service ayant besoin de cette donnée peut en disposer dans son propre périmètre et n’a pas besoin de faire appel à un autre service.
Dans ce modèle, la donnée est répliquée dans plusieurs bases. A chaque changement, le service en charge de la gestion de cette donnée publie l’information. Les services abonnés à ces événements peuvent donc stocker ou mettre à jour la donnée dans leur propre base.
Dans le cas d’une banque en ligne, le client est une donnée centrale. En effet, toutes les entités du modèle sont reliées à un client. Dans le cadre d’un modèle décentralisé, toute ou partie des informations clients peuvent donc être répliquées et stockées dans les bases locales gérées par les différents services.
Figure 14 – Exemple de réplication d’une donnée dans plusieurs services
Ainsi lors d’un traitement, les informations du client peuvent directement être consultées dans la base locale du service sans devoir faire un appel au service client.
Par exemple lors d’une opération sur un compte titre, il est nécessaire de vérifier que le client a bien rempli le questionnaire permettant de définir son profil investisseur. Si cette information est répliquée dans la base du service Titre, il n’est pas nécessaire de faire un appel au service client pour la récupérer et le traitement peut rester local au service titre.
Avantages
L’accès à la donnée est beaucoup plus rapide. Les temps de réponse sont donc meilleurs.
Il n’y a pas de problème de montée en charge car l’appel systématique au service client n’est plus nécessaire. Donc globalement, des temps de réponse plus rapide, une meilleure disponibilité et scalabilité. On élimine la dépendance au service client.
Inconvénients
La gestion de la cohérence des données est plus complexe. En effet, certaines données étant répliquées, la synchronisation n’est pas immédiate. On est dans un modèle de cohérence de la donnée à terme. La donnée est cohérente lorsque toutes les opérations de synchronisation sont terminées (Modèle Eventually consistent). Par ailleurs, en cas de désynchronisation, la remise en cohérence de la donnée dans toutes les bases est beaucoup plus complexe à gérer.
Quel modèle choisir ?
Les deux modèles présentent des avantages et des inconvénients. Il est important de choisir le modèle adapté selon le cas d’usage. Dans les faits, les deux modèles dont généralement utilisés conjointement.
Dans le cas d’une donnée utilisée par de nombreux services, il est intéressant d’opter pour une réplication de cette donnée afin d’éviter les contentions en cas d’augmentation de la charge.
En revanche pour une donnée spécifique à un service ou utilisée dans un nombre limité de traitement , il est préférable d’opter pour un modèle centralisé plus simple à opérer et à maitriser.
Exemples de cas d’usage
Ecriture haute fréquence : Prise de commande sur un site de commerce électronique
Dans le cas d’un site de commerce électronique, la prise de commande est un processus critique. A l’occasion de certains événements tel que le Black Friday ou pendant la période de noël, la charge peut augmenter de manière très importante. Dans ce cas, l’écriture directe des données de la commande en base de données peut conduire à une saturation de la base et donc à des erreurs en cascade.
Figure 15 – Ecriture directe des commandes en base de données
On est ici dans un cas d’école ou le processus d’enregistrement de la commande doit s’effectuer en asynchrone. Il s’agit en effet de découpler l’événement de validation de la commande de son écriture physique dans la base de données.
Ainsi lors de la validation du panier d’achat, l’information doit être transmise sous la forme d’un événement dans une file de messages. Ces messages sont ensuite consommés par un nombre maitrisé d’instances en charge de stocker les commandes en base de données. L’écriture dans la base est ainsi régulée et décorrélée du nombre de sessions client.
Figure 16 – Gestion asynchrone de l’écriture des commandes en base de données
Accès rapide à une donnée massivement lue dans le cadre de plusieurs workflow
Prenons a nouveau l’exemple d’une plateforme de commerce électronique. Dans ce type de modèle, les données client sont centrales et utilisées dans de nombreux traitements tels que l’enregistrement de la commande, le traitement de la commande, les diverses notifications, le processus de livraison, les campagnes marketing, ….
Un modèle centralisé des données client va conduire à une très forte charge d’appel au service en charge de la gestion de ces données. En effet, dans l’ensemble des processus cités précédemment et gérés par divers services, les données client sont nécessaires et cela va conduire à un appel synchrone au service client afin de la récupérer.
Il est donc préférable dans ce cas d’opter pour un modèle décentralisé de ces données, ou un sous ensemble de ces données est répliqué dans les différents services devant les utiliser.
Par exemple, le service en charge de la gestion des campagnes Marketing aura principalement besoin du nom, prénom et de l’adresse email du client.
Alors que le service expédition aura besoin également de l’adresse du client.
Chaque service doit donc répliquer uniquement les données dont il a besoin pour ses traitements.
Demande d’ouverture d’un compte bancaire en ligne
L’ouverture d’un compte bancaire en ligne est typiquement un processus long devant être traité par un ensemble de sous processus asynchrones.
Le processus à implémenter est le suivant :
- Le client doit entrer ses données personnelles : nom, prénom, adresse, email, téléphone, …
- Le client doit transmettre en ligne les documents qui lui sont demandés : carte d’identité, justificatif de domicile, …
- Les documents fournis doivent être vérifiés et validés
- La banque doit vérifier que le client n’est pas interdit bancaire en banque de France
- Le compte doit être alimenté avec un virement initial
- Enfin, le compte n’est activé que lorsque les informations et les documents transmis sont validés et que le virement initial a bien été reçu.
Le traitement de ce processus va faire intervenir plusieurs services :
- Le service Client pour l’enregistrement et les traitement des données du client
- Le service Compte pour la création du compte bancaire
- Le service Virement pour le traitement du virement initial.
L’appel à des partenaires externes tels que la Banque de France ou bien IDnow pour la validation des documents transmis, seront également nécessaires.
Figure 17 – Processus d’ouverture d’un compte courant en ligne
[1] https://www.forbes.com/sites/forbescoachescouncil/2021/02/04/why-is-agility-so-important-to-the-success-of-companies, Why Is Agility So Important To The Success Of Companies ? , publié le 4 février 2021
[2] https://solace.com/resources/white-papers/wp-download-idc-eda-survey?utm_source=web&utm_medium=referral&utm_content=pr_2023-idc-survey&utm_campaign=eda_survey2023, Unlocking the Exponential Business Value of Real-Time Event-Driven Data Flows, publié en avril 2023
[3] Jonas Bonér, Dave Farley, Roland Kuhn, and Martin Thompson, « Le Manifeste Réactif », reactivemanifesto.org, 16 septembre 2014.
