Définition et importance de l'architecture pilotée par les événements

L'architecture pilotée par les événements est une approche de conception logicielle qui donne aux entreprises les moyens de réagir instantanément à tout changement d'état significatif. Imaginez une entreprise capable de réagir dès que quelque chose d'important se produit, par exemple un achat en ligne par un client, la détection d'une défaillance imminente par un capteur, la baisse du cours d'une action ou une alerte de sécurité. Ces changements, que l'on appelle événements, se produisent en permanence, dans toutes les entreprises et dans tous les secteurs. Le succès des entreprises tient à leur réactivité.

C'est là que l'architecture pilotée par les événements (EDA) entre en jeu. Au lieu d'attendre les mises à jour planifiées ou de se fier à des systèmes rigides et étroitement liés, l'architecture pilotée par les événements soutient la communication asynchrone entre les applications à l'aide de composants à couplage lâche. Chaque élément du système peut agir indépendamment des autres, c'est-à-dire sans connaître les rouages de l'autre. Ce fonctionnement simplifie le développement, l'adaptation et l'innovation.

Pour résumer, les entreprises qui utilisent une architecture pilotée par les événements dans leurs systèmes modernes proposent des expériences plus rapides et personnalisées, automatisent leurs opérations et restent agiles, même en cas de hausse du volume de demandes et de données. En adoptant l'architecture pilotée par les événements, les entreprises passent d'une approche réactive à proactive. Elles atteignent la vitesse, le niveau de flexibilité et de résilience requis pour prospérer dans un monde digital dynamique.

Qu'est-ce qu'un événement ?

Un événement est une action ou un changement d'état qui a un effet sur l'entreprise, par exemple un client qui effectue un paiement par carte de crédit, un passager qui s'enregistre pour un vol, un utilisateur qui réinitialise son mot de passe ou un entrepôt qui met à jour ses stocks. Pour le dire autrement, un événement est un message court qui indique que « quelque chose vient de se produire », ce qui donne aux autres éléments du système l'occasion de réagir sans attendre.

Une entreprise pilotée par les événements est une entreprise qui capture ces événements et y réagit au fur et à mesure. Voici quelques exemples d'événements courants :

• Un paiement est accepté ou refusé
• Un utilisateur se connecte ou se déconnecte
• Le stock descend en dessous d'un seuil
• Une livraison quitte l'entrepôt ou arrive à destination
• Une violation de sécurité déclenche une alerte
• Un programme de fidélité met à jour le solde de points
• Une équipe support crée un ticket
• Un client met à jour son adresse d'expédition
• Un nouvel utilisateur crée un compte
• Un client soumet un avis sur un produit
• Un abonné renouvelle ou résilie son abonnement

Composants clés de l'architecture pilotée par les événements

Dans un souci de cohérence, les modèles d'événements définissent la structure et le format des événements, notamment les zones, les types de données et les règles d'interprétation.

Dans une architecture pilotée par les événements, les applications jouent le rôle de diffuseurs (elles produisent ou capturent les événements) ou de consommateurs (elles traitent les événements et prennent des mesures en conséquence). Les diffuseurs transmettent en temps réel les événements aux consommateurs via un courtier d'événements, à savoir un middleware orienté messagerie. Les consommateurs peuvent ensuite traiter l'événement et déclencher leurs propres actions, workflows ou événements. Cette conception favorise la réactivité en temps réel et les décisions intelligentes à mesure que les données affluent.

Le courtier d'événements gère les canaux d'événements qui connectent les diffuseurs et les consommateurs ; garantit la fiabilité de la transmission et offre souvent des fonctionnalités telles que le filtrage, la persistance et la rediffusion. En découplant les diffuseurs et les consommateurs, le courtier d'événements rend le système plus résilient et évolutif.

Dans une architecture très simple au sein de laquelle un seul diffuseur et un seul consommateur communiquent directement, les courtiers sont facultatifs. Mais dans la plupart des entreprises, plusieurs sources envoient des événements à plusieurs consommateurs ; un courtier, voire un réseau de courtiers (également appelé « maillage d'événements »), est donc nécessaire. L'utilisation d'un courtier ou d'un maillage d'événements entraîne un « couplage lâche » des applications.

Communication synchrone versus asynchrone

Dans une architecture pilotée par les événements avec une communication synchrone, le diffuseur attend que le destinataire traite l'événement et y réagisse. Tel est le cas par exemple lorsqu'un client Web envoie une requête HTTP et attend la réponse du serveur. La communication synchrone présente généralement un couplage étroit et s'avère plus lente en cas de charge élevée. Elle « empêche » le diffuseur d'accomplir sa prochaine tâche tant qu'il n'a pas reçu la réponse du consommateur.

Dans une architecture pilotée par les événements avec une communication asynchrone, le diffuseur n'attend pas une réponse immédiate. Il peut poursuivre ses tâches en attendant que le consommateur traite le message. Tel est le cas par exemple lorsqu'un système publie un événement via un courtier d'événements et que le consommateur le traite de façon indépendante. La communication asynchrone n'est pas bloquante. Elle est évolutive, avec un couplage lâche, ce qui la rend idéale pour les systèmes en temps réel et distribués.

Modèles fondés sur les requêtes versus les événements dans une architecture pilotée par les événements

Dans le modèle piloté par les requêtes, l'interaction commence par la requête d'un consommateur d'événements auprès d'un serveur, et se poursuit avec la réponse du serveur. Ce modèle fonctionne en mode pull : le consommateur demande activement des données ou des services au serveur lorsqu'il a en besoin, car il ne reçoit pas de mises à jour automatiques. Il peut être synchrone ou asynchrone. Les modèles pilotés par les requêtes sont répandus dans les applications Web et les API traditionnelles.

Dans le modèle piloté par les événements, l'interaction commence par un événement, à savoir un changement d'état ou une action qui déclenche un traitement. Les composants réagissent automatiquement en cas d'événement (par exemple, publication/abonnement). Ce modèle fonctionne en mode push : le système transmet automatiquement les événements et les mises à jour en temps réel au consommateur, sans attendre de demande de sa part. Les modèles pilotés par les événements sont asynchrones, découplés et gages de réactivité en temps réel.

Pour résumer, voici les principales différences entre ces modèles : dans les modèles pilotés par les requêtes, les utilisateurs demandent des données lorsqu'ils en ont besoin ; les modèles pilotés par les événements réagissent automatiquement.

Modèles courants d'architecture pilotée par les événements

Les modèles d'architecture pilotée par les événements sont des approches de conception répandues qui déterminent comment un système piloté par les événements capture, traite et consomme les événements. Les modèles fournissent des stratégies réutilisables de gestion de la communication et des changements d'état. Ces stratégies sont évolutives et découplées. Les entreprises utilisent les modèles d'architecture pilotée par les événements durant la conception et la mise en œuvre afin de relever des défis courants. On peut notamment citer la diffusion des événements, la cohérence des données et l'évolutivité dans des environnements asynchrones à couplage lâche.

Dans une architecture pilotée par les événements, les événements peuvent être transmis de quatre manières :

• Publication/abonnement («  pub/sub  ») : dans le modèle pub/sub, les consommateurs d'événements s'abonnent aux messages et aux canaux publiés par les diffuseurs d'événements. Lorsqu'un événement est publié, il est directement envoyé à tous les abonnés via un courtier. Pour éviter les doublons, les événements ne peuvent pas être rejoués et ne sont plus accessibles une fois consommés ; ils sont supprimés par le courtier.
• Flux d'événements : les diffuseurs publient des flux d'événements entiers via un courtier. Les consommateurs s'abonnent au flux et peuvent le lire depuis n'importe où, en consommant uniquement les événements pertinents pour eux. Dans ce modèle, les événements sont conservés par le courtier même après leur consommation.
• Séparation des responsabilités des requêtes de commande (CQRS) : dans le modèle CQRS, la couche de conception et d'architecture sépare les opérations de lecture et d'écriture (deux modèles). Le modèle Commandes met à jour l'état, tandis que le modèle Requêtes lit l'état. Dans une architecture pilotée par les événements, le modèle CQRS s'appuie souvent sur les événements pour propager des changements asynchrones, ce qui améliore l'évolutivité et la performance des systèmes complexes.
• Sourcing d'événements : grâce au sourcing d'événements, le système enregistre chaque changement d'état comme un événement dans un journal « append-only » au lieu de conserver uniquement l'état actuel de l'entité. L'état actuel peut être reconstitué en rejouant ces événements. Ce sourcing fournit une piste d'audit complète et soutient les scénarios de retour dans le passé et de restauration.

Styles de traitement des événements

Le style de traitement des événements décrit comment le système détecte les événements, les interprète et y réagit. Il définit la complexité de la logique, la temporalité et les relations entre les événements compris par le système. Il existe trois approches de traitement des événements une fois qu'ils sont parvenus au consommateur : le traitement d'événement simple, le traitement d'événement complexe et le traitement de flux d'événements.

1. Traitement d'événement simple : les consommateurs traitent chaque événement tel qu'il est reçu. Voici quelques exemples :

• Un client passe commande, ce qui déclenche l'envoi d'un e-mail de confirmation et la mise à jour des stocks par le système.
• Une demande de réinitialisation de mot de passe déclenche l'envoi immédiat d'un e-mail contenant un lien sécurisé.
• Un paiement déclenche la génération et l'envoi d'un reçu au client.
• La connexion d'un utilisateur est instantanément enregistrée pour des raisons de suivi et de sécurité.

2. Traitement d'événement complexe : les consommateurs traitent une série d'événements pour détecter des modèles et effectuer des actions en fonction du résultat. Voici quelques exemples :

• La réalisation de plusieurs transactions d'un montant élevé dans un intervalle court déclenche une alerte pour fraude.
• La hausse de la température associée à l'augmentation des vibrations indique une défaillance imminente de l'équipement.
• Des tentatives de connexion de différents pays en l'espace de quelques minutes déclenchent un avertissement de sécurité.
• L'abandon répété du panier par un seul et même utilisateur déclenche l'envoi d'une remise personnalisée.

3. Traitement des flux d'événements : les consommateurs traitent un flux constant de données (données mobiles) et prennent des mesures en temps réel à l'aide d'une plateforme de flux de données. Voici quelques exemples :

• Les fluctuations du cours des actions déclenchent l'exécution immédiate de transactions conformément à des règles prédéfinies.
• Les tableaux de bord du ressenti sont mis à jour sans attendre en cas de hausse des mentions sur les réseaux sociaux.
• La technologie de télémétrie des véhicules connectés procède à l'ajustement dynamique des feux de circulation.
• Les données du flux de clics d'un site de e-commerce alimentent les recommandations produits en temps réel.

Les entreprises choisissent leur style de traitement des événements en fonction de leurs besoins spécifiques et de leurs cas d'utilisation.

Mode d'emploi de l'architecture pilotée par les événements

Une architecture pilotée par les événements est un modèle d'intégration conçu pour publier, capturer, traiter les événements et y répondre en temps réel dans des systèmes distribués. Lorsqu'un événement se produit dans une application, un message est automatiquement envoyé à toutes les autres applications qui doivent en avoir connaissance, afin qu'elles puissent à leur tour prendre des mesures en conséquence.

Voici comment fonctionne l'architecture pilotée par les événements, étape par étape :

1. Un événement se produit : un changement d'état significatif se produit, par exemple un client passe commande, un capteur détecte un pic de température ou un paiement échoue.
2. Le diffuseur soumet l'événement : l'application dans laquelle s'est produit l'événement agit comme diffuseur et publie l'événement via un courtier.
3. Le courtier transfère l'événement : le courtier d'événements agit comme intermédiaire afin de gérer les canaux d'événements et de transmettre l'événement à tous les consommateurs intéressés. Il veille à la fiabilité, à l'évolutivité et au découplage de la communication.
4. Le consommateur réagit à l'événement : les applications ou les services qui se sont abonnés au canal d'événements traitent l'événement et prennent les mesures nécessaires (mettre à jour les stocks, envoyer un e-mail de conformation, déclencher une alerte, etc.).

Les architectures fondées sur les événements étant asynchrones et découplées, les applications n'ont pas besoin d'avoir connaissance les unes des autres pour partager des informations et exécuter des tâches en temps réel. Les informations sur les événements, ou les messages, peuvent circuler librement et automatiquement entre les applications. Par conséquent, ce modèle d'architecture est beaucoup plus rapide et résilient que les modèles traditionnels pilotés par les requêtes et les réponses, dans lesquels une application doit demander à une autre les informations spécifiques dont elle a besoin et attendre la réponse avant de passer à la tâche suivante. De plus, compte tenu de sa nature découplée, l'architecture pilotée par les événements est généralement considérée comme une bonne pratique dans la communication de microservices.

Cas d'utilisation et exemples concrets

L'architecture pilotée par les événements crée des expériences digitales modernes dans tous les secteurs, de la banque à la logistique en passant par le Retail et la production. En encourageant l'automatisation pilotée par l'IA, la veille événementielle et la réactivité en temps réel, l'architecture pilotée par les événements aide les entreprises à moderniser leur IT, à découpler les systèmes hérités et à fluidifier leurs opérations dans les environnements multiclouds.

Les exemples suivants illustrent le fonctionnement de l'architecture pilotée par les événements en pratique.

Secteur de la restauration

1. Un étudiant commande une pizza à l'aide d'une application de livraison de repas. L'application enregistre ses informations de base (nom, adresse, informations de paiement et commande) et publie l'événement « commande de pizza ».
2. La pizzeria s'abonne à l'événement, traite la commande et publie son propre événement « commande prête » sur le service de livraison.
3. Ensuite, le service affecte un chauffeur-livreur, détermine l'heure d'arrivée prévue et avertit le client que sa pizza est en route.

E-commerce

1. Un client entre les informations de sa carte de crédit sur un site de e-commerce, qui publie l'événement « paiement soumis ».
2. Le système de paiement s'abonne à l'événement, traite le paiement et émet son propre événement « paiement traité », indiquant s'il est accepté ou refusé, puis le renvoie à l'IU du site Web.
3. L'IU affiche le statut du paiement au client et l'invite à suivre les étapes suivantes.

Voici d'autres exemples d'architecture pilotée par les événements :

Télémétrie IoT

• Une usine intelligente diffuse des données de capteurs pour détecter des pics de température et prévenir toute défaillance d'équipement.
• Des véhicules connectés envoient des données de télémétrie afin d'optimiser la circulation de façon dynamique.
• Des appareils domotiques intelligents publient des événements de consommation d'énergie pour déclencher la génération de conseils pour économiser.

Analytique et veille événementielle

• Un détaillant analyse les données du flux de clics en temps réel pour personnaliser les recommandations produits.
• Une banque assure le suivi des modèles de transactions pour anticiper la fraude.
• Une entreprise du secteur logistique utilise les données de flux pour estimer les retards de livraison et réacheminer les envois.

Automatisation

• Un système RH accorde automatiquement l'accès à un logiciel à une nouvelle recrue, et affecte les licences et autorisations requises.
• Un système de soins lance automatiquement une alerte lorsque les constantes d'un patient dépassent les seuils critiques.
• Une plateforme cloud gère les ressources de façon dynamique en fonction des événements relatifs à la charge de travail.

Transactions financières

• Une plateforme de paiement publie un événement « paiement soumis » pour initier une recherche de fraude avant l'approbation.
• Une plateforme de trading exécute des ordres d'achat ou de vente en fonction des fluctuations du cours des actions en temps réel.
• Une banque comptabilise les dépôts et actualise les soldes en temps réel.

Supply Chain

• Un entrepôt met à jour les niveaux de stock et génère automatiquement des ordres de réapprovisionnement.
• Un service de livraison redirige les chauffeurs en temps réel en fonction des événements liés à la circulation et à la météo.
• Un fabricant ajuste ses plans de production d'après la demande en temps réel.

Modernisation IT et découplage des systèmes hérités

• Une entreprise décharge son ordinateur central en publiant les événements de gestion sur des services cloud modernes pour les fonctions clés.
• Une entreprise expose les interfaces d'événements en temps réel en lien avec un ERP hérité afin que les nouvelles applications puissent réagir sans attendre et sans toucher au backend.
• Une entreprise reporte les événements d'un ancien CRM dans une plateforme SaaS moderne pour assurer la synchronisation des deux systèmes pendant une migration progressive.

Notifications

• Un fournisseur dans le secteur de l'eau et de l'énergie notifie sans délai ses clients en cas de panne de courant dans leur zone et met à jour les informations sur l'avancement de l'équipe d'intervention.
• Une application de voyage envoie des alertes en temps réel en cas de changement de porte afin que les passagers puissent ajuster leurs plans immédiatement.
• Un service de streaming envoie des recommandations personnalisées lorsqu'un utilisateur termine une série.
• Un système de sécurité lance des alertes lorsqu'il détecte des activités de connexion suspectes.

Voici des cas typiques d'utilisation de l'architecture pilotée par les événements :

• Un client clique en ligne sur un produit et le système répond en générant des recommandations de produits similaires.
• Un détaillant surveille les transactions mondiales pour détecter les éventuelles fraudes et signale les achats suspects à la société émettrice de cartes de crédit.
• La fonctionnalité d'engagement client en temps réel se fonde sur le flux continu de données sur le comportement des utilisateurs pour personnaliser les offres ou appliquer une tarification dynamique pendant la session d'achat.
• La fonctionnalité de suivi de la santé publie les constantes des patients issues des appareils connectés pour alerter les praticiens en cas de dépassement de seuils.
• Le service opérationnel d'une ville intelligente gère les feux de circulation et les horaires des transports en commun en fonction des événements météorologiques et de circulation en temps réel.
• La fonctionnalité de détection des cybermenaces repère les activités suspectes sur le réseau ainsi que les tentatives d'accès non autorisées en temps réel, et y réagit.
• La fonctionnalité d'optimisation des ressources cloud fait automatiquement évoluer les ressources dans les environnements multiclouds lors de pics de la charge de travail.

Avantages d'une architecture pilotée par les événements

Les entreprises peuvent tirer parti des avantages d'une architecture pilotée par les événements au sein de leurs systèmes modernes. Voici les principaux avantages de l'architecture pilotée par les événements :

1. Réactivité en temps réel et workflows intelligents : dans une architecture pilotée par les événements, le système réagit instantanément aux événements et déclenche automatiquement des workflows et des décisions en temps réel. C'est une procédure particulièrement importante en période de pic de demandes, par exemple lors de ventes importantes ou en période de fêtes. Les opérations peuvent appliquer cette réactivité aux opérations quotidiennes et améliorer de nombreux aspects, dont l'automatisation de la Supply Chain, la détection de la fraude et l'engagement client personnalisé.
2. Vitesse et efficacité de la communication asynchrone : les applications d'une architecture pilotée par les événements communiquent de manière asynchrone, c'est-à-dire que les diffuseurs publient des messages sur les événements sans attendre que les consommateurs les reçoivent. Cette approche non bloquante améliore les performances, réduit la latence et garantit l'absence de goulets d'étranglement lors du traitement de grands volumes d'événements.
3. Flexibilité et évolutivité via le découplage et le couplage lâche : dans une architecture pilotée par les événements, les composants sont découplés ou à couplage lâche. Ils fonctionnent de façon autonome et ne dépendent donc pas de la disponibilité ou de la logique interne de l'un ou de l'autre. Ce mode de fonctionnement permet de mettre à jour, tester et déployer des services facilement, sans perturber le système dans son ensemble. Le découplage facilite aussi l'ajout de diffuseurs et de consommateurs : l'entreprise évolue en toute fluidité en fonction de ses besoins.
4. Résilience et isolement des pannes : lorsque les services sont découplés, la défaillance d'un composant n'affecte pas le système tout entier. Chaque défaillance est indépendante, ce qui rend l'architecture plus durable et résistante aux pannes que les modèles traditionnels au couplage étroit.
5. Intégration pérenne : le couplage lâche et la conception asynchrone font de l'architecture pilotée par les événements une solution de choix pour la modernisation IT, le découplage des systèmes hérités et les opérations multiclouds. Les entreprises deviennent assez flexibles pour intégrer de nouvelles technologies comme l'automatisation pilotée par l'IA et la veille événementielle sans avoir à réécrire les systèmes core.

Défis, limites et bonnes pratiques

Même si les architectures pilotées par les événements présentent des avantages de taille, elles posent aussi des défis de conception et d'exploitation que les entreprises doivent anticiper. Lors de la mise en œuvre de cette architecture, n'oubliez pas de tenir compte des défis, limites et bonnes pratiques ci-dessous. Vous aurez alors l'assurance d'instaurer des systèmes pilotés par les événements évolutifs, résilients et bien gérés.

Défis

• Complexité des systèmes distribués : la gestion d'un maillage de courtiers d'événements dans plusieurs environnements est source de complexité au niveau de l'architecture. Une planification et une expertise avancées sont requises pour concevoir les flux d'événements, assurer la cohérence des modèles et gérer la communication asynchrone. En l'absence de contrôles de conception adaptés, les entreprises risquent de faire face à un chaos si le volume d'événements, de diffuseurs et de consommateurs augmente.
• Gouvernance et conformité : compte tenu de la circulation d'événements dans des environnements hybrides et multiclouds, l'application des politiques de gouvernance (protection des données, sécurité, conformité réglementaire, etc.) se complique. Les entreprises ont besoin de cadres de gouvernance solides pour prévenir les fuites de données et les accès non autorisés tout en gardant le contrôle sur des environnements à l'expansion rapide.
• Débogage et observabilité : le dépannage est plus difficile dans un système asynchrone au couplage lâche que dans les architectures traditionnelles. Des fonctionnalités avancées de suivi, de traçage et de rediffusion d'événements sont requises pour identifier la cause profonde des défaillances et des retards. Ce défi est d'autant plus important lorsque les équipes tentent de résoudre des problèmes issus de chaînes d'événements complexes ou de venir à bout de symptômes d'un chaos d'événements.

Zoom sur l'intégration du maillage d'événements

Le maillage d'événements est une fonctionnalité architecturale qui connecte différents courtiers d'événements dans divers hyperscalers et environnements privés, hybrides et multiclouds. Le maillage d'événements offre un ensemble complet de services avancés : flux d'événements, gestion des événements, surveillance, routage dynamique des messages et filtrage fin. Grâce à la connexion des courtiers au sein d'un maillage organisé, les entreprises peuvent :

• Réduire la complexité grâce au routage et à la gestion centralisés des événements.
• Assurer la gouvernance à l'aide de catalogues d'événements, de modèles et du suivi.
• Améliorer l'observabilité via le traçage d'événements, la rediffusion et l'analytique avancée.
• Favoriser l'évolutivité et la résilience dans les environnements hybrides et multiclouds.

Pilier des systèmes modernes, le maillage d'événements est une couche essentielle des architectures évolutives et pilotées par les événements en temps réel. Il garantit une réactivité instantanée tout en simplifiant l'intégration, en réduisant le chaos autour des événements et en renforçant les capacités de dépannage dans les environnements distribués.

Limites de l'architecture pilotée par les événements

• Frais généraux opérationnels : les systèmes pilotés par les événements ont besoin d'outils spécialisés dans la gestion des événements, la validation des modèles et le suivi, ce qui peut augmenter la complexité opérationnelle.
• Compétences : la mise en œuvre et la maintenance du maillage d'événements et des modèles d'architecture pilotée par les événements nécessitent une expertise dans les systèmes distribués, les courtiers d'événements et les plateformes d'intégration.
• Risques de latence : même si l'architecture pilotée par les événements est conçue à des fins de réactivité en temps réel, un routage mal configuré ou une surcharge des courtiers peut entraîner une certaine latence.

Bonnes pratiques de l'architecture pilotée par les événements

• Standardiser les modèles et les contrats d'événements : utilisez les registres de modèles et imposez la validation pour assurer la cohérence entre les diffuseurs et les consommateurs.
• Mettre en œuvre une gouvernance forte : élaborez des politiques claires en matière de responsabilité, de sécurité et de conformité. Tirez parti des outils d'audit et de contrôle des accès.
• Améliorer l'observabilité : déployez des solutions de suivi et de traçage pour suivre les flux d'événements, repérer les anomalies et simplifier le débogage.
• Intégrer l'évolutivité et la résilience dans la conception : utilisez des fonctionnalités de maillage d'événements telles que le routage dynamique et le filtrage fin pour optimiser les performances et la résistance aux défaillances.
• Automatiser à l'aide de l'IA et de la veille événementielle : intégrez l'analytique et l'automatisation pilotées par l'IA pour anticiper les problèmes, optimiser le routage et améliorer la prise de décision en temps réel.

Caractéristiques de l'architecture pilotée par les événements

De par ses caractéristiques de base, l'architecture pilotée par les événements convient parfaitement aux environnements distribués, hybrides et multiclouds.

• Communication asynchrone : une caractéristique essentielle de l'architecture pilotée par les événements. Au lieu d'attendre une réponse directe comme dans les modèles traditionnels pilotés par les requêtes, les applications publient des événements et continuent de fonctionner sans ralentissement. Ce style non bloquant veille à l'instantanéité des interactions dans les systèmes distribués et améliore la réactivité, même en cas de charge importante.
• Couplage lâche : les applications n'ont pas besoin de connaître la disponibilité, la structure d'API ou la logique interne des unes et des autres. Elles communiquent simplement via des événements acheminés par un courtier ou un maillage d'événements. Grâce à l'indépendance des diffuseurs et des consommateurs, les équipes peuvent ajouter, mettre à jour et remplacer des services sans perturber le système dans son intégralité. Il gagne alors en agilité et résiste mieux aux défaillances.
• Évolutivité indépendante : comme les composants sont découplés, les services individuels peuvent évoluer à la hausse ou à la baisse en fonction de la demande. Aucun changement n'est nécessaire dans les applications en amont ou en aval. SAP met en avant cet avantage clé de l'intégration pilotée par les événements, en particulier dans les environnements hybrides et multiclouds, car les pics de charge et les charges de travail distribuées doivent y être gérés efficacement.

Ensemble, ces caractéristiques font de l'architecture pilotée par les événements une approche puissante de création de systèmes résilients, flexibles, instantanés et prêts à se développer — et ce, pour la prise en charge de microservices comme l'intégration d'environnements cloud ou l'activation d'applications fondées sur des processus pilotés par les événements.

FAQ