Une entreprise héberge une application sur des fonctions AWS Lambda invoquées par une API Amazon API Gateway. Les fonctions Lambda enregistrent les données client dans une base de données Amazon Aurora MySQL. Chaque fois que l'entreprise met à niveau la base de données, les fonctions Lambda ne parviennent pas à établir de connexions à la base de données tant que la mise à niveau n'est pas terminée, ce qui entraîne la perte de données client pour certains événements. Un architecte de solutions doit concevoir une solution qui stocke les données client créées pendant les mises à niveau de la base de données. Quelle solution répondra à ces exigences ?

La solution correcte consiste à utiliser une file d'attente Amazon SQS FIFO. Lorsque la base de données Aurora est indisponible pendant une mise à niveau, les fonctions Lambda peuvent envoyer les données client à la file d'attente SQS. Une fonction Lambda distincte peut ensuite interroger cette file d'attente et insérer les données dans la base de données une fois qu'elle est à nouveau disponible. Cela garantit qu'aucune donnée n'est perdue et que les requêtes sont traitées dans l'ordre (FIFO). Provisionner un proxy Amazon RDS ne résoudrait pas le problème de l'indisponibilité de la base de données sous-jacente pendant la mise à niveau. Augmenter le temps d'exécution des fonctions Lambda et ajouter un mécanisme de nouvelle tentative ne garantirait pas la persistance des données si la base de données est hors ligne pendant une période prolongée. Persister les données dans le stockage local de Lambda n'est pas une solution durable ou évolutive, car le stockage local est éphémère et ne peut pas être facilement accédé par d'autres fonctions Lambda.