Event Driven Architecture avec des exemples sur AWS

Imagine que tu dois suivre une recette pour faire un gâteau. La recette indique qu’il faut mélanger les ingrédients dans un certain ordre en respectant bien les quantités pour que le gâteau soit réussi. Si tu mélanges les ingrédients dans le mauvais ordre, le gâteau ne sera pas bon

L’architecture orientée événements fonctionne de la même manière. par exemple, lorsque tu cliques sur un bouton sur un site web, cela déclenche un événement. L’architecture orientée événements s’assure que tous ces événements se produisent dans le bon ordre et de la bonne façon pour que l’application fonctionne comme il faut.

D’une manière générale dans les architectures orientée événements nous utilisons des “files d’événements”.

La file d’événements indique à l’ordinateur dans quel ordre les événements doivent se produire. Lorsqu’un événement se produit, l’ordinateur le vérifie sur la liste pour savoir ce qu’il doit faire ensuite.

Parmi les patterns les plus connus dans une event driven architecture il y a le pattern “Publish/Subscribe” qui permet à un éditeur (ou “publisher”) de publier des événements à un ou plusieurs abonnés (ou “subscribers”) qui sont intéressés par ces événements. Les abonnés reçoivent uniquement les événements auxquels ils sont abonnés 😉

Vous pouvez utiliser Amazon SNS pour publier des messages à des sujets (topics) et les abonnés peuvent s’abonner à ces sujets pour recevoir les messages. Par exemple, vous pouvez configurer un sujet Amazon SNS pour les notifications de commandes et permettre aux abonnés d’être avertis lorsque de nouvelles commandes sont passées. Les abonnés peuvent être des files d’attente AWS SQS (Simple Queue Service) qui traitent les commandes.

Prenons un exemple d’une architecture event driven sur AWS.

Voici un scénario d’utilisation : imaginons que vous ayez un site Web qui permet aux utilisateurs de télécharger des fichiers. Vous souhaitez que chaque fois qu’un utilisateur télécharge un fichier, un message soit envoyé à un service de messagerie, tel que Slack, pour que les administrateurs soient informés.

Comment implémenter cela via AWS ?

Pour cela nous allons utiliser les services AWS suivants:

1. EventBridge : c’est un service qui permet de connecter différents services AWS et de les faire communiquer entre eux via des événements.

2. AWS S3: c’est un srevice se stockage d’objets

Exemple: on peut configurer S3 pour envoyer un événement sur EventBridge une fois un fichier a été déposé ou téléchargé

Pour répondre à notre problématique d’envoi de notifications Slack on va procéder de la façon suivante:

Une fois un fichier est télécharger sur s3 on peut configurer EventBridge pour surveiller les événements sur le bucket S3 où les fichiers sont stockés. Lorsqu’un fichier est téléchargé, cela déclenche un événement qui sera envoyé à EventBridge. Vous pouvez ensuite configurer EventBridge pour acheminer cet événement vers une fonction AWS Lambda, qui sera chargée de publier un message sur un canal Slack et c’est résolu 🤩

Prenons un autre exemple 😉

Supposons que vous ayez un site de e-commerce. vous souhaitez que chaque fois qu’un client passe une commande, l’adresse de livraison soit vérifiée pour s’assurer que la commande peut être livrée dans cette région. Si l’adresse de livraison est invalide, vous souhaitez que la commande soit annulée et que le client soit informé.

Pour mettre en place cette architecture orientée événements, vous pouvez utiliser les services AWS suivants :

1. API Gateway : permet aux clients de passer des commandes via une API RESTful.
2. AWS Lambda : exécute le code en réponse à un événement, comme une commande passée par un client.
3. Amazon EventBridge : connecte les différents services AWS et permet de transmettre des événements entre eux.
4. Amazon SNS : service de messagerie qui peut envoyer des notifications par e-mail, SMS ou autres.

Voici comment cela pourrait se faire

1. Un client passe une commande via l’API Gateway.
2. L’API Gateway déclenche un événement qui est envoyé à EventBridge.
3. EventBridge achemine l’événement vers une fonction AWS Lambda qui effectue la vérification de l’adresse de livraison.
4. Si l’adresse de livraison est valide, la commande est envoyée à une file d’attente AWS SQS en vue d’un traitement pour systéme de commande
5. Si l’adresse de livraison est invalide, la commande est annulée et un message est envoyé à SNS pour informer le client.
6. SNS envoie un message au client pour l’informer de l’annulation de la commande.

En utilisant une architecture orientée événements, on peut créer des applications qui sont plus flexibles, fiables et rapides. Cela signifie que l’application peut facilement s’adapter à de nouveaux besoins, éviter les pannes de service, traiter les événements en temps réel et être modifiée ou mise à jour plus facilement . Cette approche est idéale pour les applications qui nécessitent une grande réactivité et qui ont besoin de s’adapter à des charges de travail variables..

En somme, l’architecture orientée événements permet une plus grande flexibilité, fiabilité et scalabilité que les architectures traditionnelles. Elle est particulièrement adaptée aux applications qui nécessitent des temps de réponse rapides et qui doivent évoluer facilement au fil du temps.