Un workflow e-commerce serverless utilise API Gateway pour invoquer une fonction Lambda qui appelle une API de stock tierce. Lors des pics de charge, l'API tierce échoue lorsqu'elle est submergée. L'entreprise a besoin d'une solution qui empêche de submerger l'API tierce. Quelle conception répond à ce besoin ?

La solution correcte utilise Amazon SQS comme tampon pour désolidariser l'API Gateway de la fonction Lambda. Cela permet de gérer les pics de trafic sans surcharger l'API tierce. En configurant une concurrence réservée pour la fonction Lambda égale au seuil de l'API tierce, on s'assure que la fonction Lambda ne traitera jamais plus de requêtes simultanément que ce que l'API tierce peut supporter, protégeant ainsi cette dernière. La première option est incorrecte car DynamoDB n'est pas conçu pour agir comme un tampon de file d'attente pour la gestion de la charge vers une API externe, et l'utilisation de DynamoDB Streams pour invoquer l'API tierce ne permettrait pas de contrôler la concurrence. La troisième option est incorrecte car Amazon SNS est un service de publication/abonnement et non une file d'attente pour la gestion de la charge. De plus, la concurrence provisionnée est utilisée pour garantir une capacité constante, pas pour limiter la concurrence en fonction d'un seuil externe. La quatrième option est incorrecte car Amazon Athena est un service d'analyse de requêtes et n'est pas adapté pour agir comme un intermédiaire de file d'attente ou un contrôleur de débit pour des appels d'API en temps réel.