Une entreprise héberge une application e-commerce à trois niveaux dans AWS. Le site web est hébergé sur Amazon S3 et s'intègre à une API sur trois instances Amazon EC2 derrière un Application Load Balancer (ALB). L'API sert du contenu frontal statique et dynamique et des workers backend qui traitent les requêtes de vente de manière asynchrone. L'entreprise s'attend à des pics soudains et importants de requêtes de vente lors des lancements de produits. Que devrait recommander un architecte de solutions pour s'assurer que toutes les requêtes sont traitées avec succès ?

La bonne réponse est d'ajouter une distribution Amazon CloudFront pour le contenu statique et une file d'attente Amazon SQS. CloudFront mettra en cache le contenu statique, réduisant ainsi la charge sur les instances EC2 et améliorant les performances pour les utilisateurs. L'ajout d'une file d'attente SQS découple le processus de réception des requêtes de vente du traitement, permettant aux requêtes d'être mises en file d'attente pendant les pics de trafic et traitées de manière asynchrone par les workers backend. Cela garantit que toutes les requêtes sont acceptées sans surcharger l'API, même lors de pics soudains. Les autres options sont moins efficaces : CloudFront pour le contenu dynamique est plus complexe et n'est pas la priorité pour le contenu frontal statique. Augmenter manuellement les instances EC2 n'est pas une solution évolutive ou automatique. Le groupe Auto Scaling est une bonne pratique, mais CloudFront pour le contenu statique est déjà couvert par S3. L'ajout de CloudFront pour le contenu statique est redondant avec S3 qui est déjà utilisé pour l'hébergement du site web. ElastiCache devant l'ALB pourrait aider à la mise en cache des données d'API, mais ne résout pas le problème fondamental de la gestion des pics de requêtes de vente asynchrones, que SQS gère mieux.