Une startup météorologique utilise Amazon DynamoDB pour stocker des données météorologiques et souhaite un nouveau service qui avertisse les responsables de quatre équipes internes chaque fois qu'un nouvel événement météorologique est enregistré. L'entreprise ne veut pas que le nouveau service affecte les performances de l'application actuelle et souhaite le moins de frais opérationnels possible. Que doit faire un architecte de solutions ?

L'activation d'Amazon DynamoDB Streams sur la table permet de capturer toutes les modifications de données (ajouts, modifications, suppressions) en temps quasi réel. L'utilisation de déclencheurs (AWS Lambda) sur ces streams permet d'exécuter du code en réponse à ces événements sans impacter les performances de l'application principale. Ce déclencheur peut ensuite publier un message sur une seule rubrique Amazon SNS, à laquelle les quatre équipes peuvent s'abonner. Cela minimise les frais opérationnels car Lambda est sans serveur et SNS gère la distribution des messages. Les transactions DynamoDB ne sont pas conçues pour la notification et n'ont pas de mécanisme intégré pour alerter des services externes. Demander à l'application actuelle de publier des messages sur quatre rubriques SNS augmenterait la complexité de l'application et pourrait potentiellement affecter ses performances. L'ajout d'un attribut personnalisé et l'utilisation d'une tâche cron avec un scan de table sont inefficaces, coûteux en termes de ressources (scans fréquents) et introduisent une latence significative.