Une entreprise exécute une API asynchrone sur Amazon API Gateway avec une fonction AWS Lambda qui stocke les requêtes utilisateur dans Amazon DynamoDB avant de les distribuer à des microservices. L'entreprise a provisionné autant de débit DynamoDB que son budget le permet, mais rencontre toujours des problèmes de disponibilité et des requêtes perdues. Que doit faire un architecte de solutions pour résoudre ce problème sans impacter les utilisateurs existants ?

L'utilisation d'Amazon SQS comme tampon entre l'API Gateway/Lambda et DynamoDB est la solution la plus efficace. SQS découple la production et la consommation des requêtes, permettant à Lambda d'écrire dans la file d'attente à un rythme élevé tandis qu'une autre fonction Lambda peut lire les messages de SQS et écrire dans DynamoDB à un rythme contrôlé, évitant ainsi les erreurs de limitation de DynamoDB. Cela assure la durabilité des requêtes et améliore la disponibilité sans affecter les utilisateurs. Les autres options sont moins appropriées : La limitation côté serveur sur API Gateway rejetterait les requêtes excédentaires, entraînant des requêtes perdues pour les utilisateurs. DAX est un cache en mémoire pour DynamoDB, optimisé pour les lectures, pas pour la mise en tampon des écritures. La création d'un index secondaire n'aide pas à résoudre les problèmes de capacité d'écriture de la table principale.