Une solution de données météorologiques reçoit des données de télémétrie de milliers de stations via une API REST API Gateway intégrée à une fonction Lambda. La fonction Lambda appelle un service tiers pour le prétraitement ; lorsque ce tiers est surchargé, le prétraitement échoue et des données sont perdues. L'architecte doit s'assurer qu'aucune donnée n'est perdue et permettre que le traitement ait lieu plus tard en cas d'échec. Que doit implémenter l'architecte ?

La bonne approche est d'utiliser Amazon SQS comme tampon entre l'API Gateway et la fonction Lambda. En envoyant les données de télémétrie à une file d'attente SQS principale, l'API Gateway peut répondre immédiatement, découplant ainsi la réception des données du prétraitement. Si la fonction Lambda échoue lors du prétraitement (par exemple, en raison d'un service tiers surchargé), SQS peut être configuré pour renvoyer le message ou le déplacer vers une file d'attente de lettres mortes (DLQ) secondaire après un certain nombre de tentatives infructueuses. Cela garantit qu'aucune donnée n'est perdue et qu'elle peut être traitée ultérieurement. La première option est incorrecte car une DLQ pour l'API ne résoudrait pas le problème de perte de données si la Lambda échoue. Les options EventBridge sont moins adaptées ici car SQS offre une meilleure gestion des messages persistants et des tentatives pour ce cas d'utilisation de file d'attente de travail.