Une application appelle DynamoDB en utilisant l'opération de bas niveau BatchGetItem et reçoit souvent des réponses qui incluent des entrées dans UnprocessedKeys. Quelles actions rendront l'application plus résiliente lorsque des UnprocessedKeys sont renvoyées ? (Choisissez-en deux.)

Lorsque DynamoDB renvoie des UnprocessedKeys après une opération BatchGetItem, cela indique que toutes les requêtes n'ont pas pu être traitées, souvent en raison de la limitation de débit (throttling) ou d'autres problèmes temporaires. Réessayer l'opération de lot en utilisant un backoff exponentiel avec un délai aléatoire est une pratique standard pour gérer les erreurs temporaires et les limitations de débit dans les systèmes distribués. Le backoff exponentiel réduit la charge sur le service et augmente les chances de succès des tentatives ultérieures, tandis que le délai aléatoire aide à éviter les "thundering herds" (multiples clients retentant simultanément). Augmenter la capacité de lecture provisionnée des tables DynamoDB auxquelles l'opération accède est une solution directe si le problème est une capacité de lecture insuffisante. En augmentant les unités de capacité de lecture (RCU), la table peut gérer un volume plus élevé de requêtes de lecture sans limitation de débit, réduisant ainsi la fréquence des UnprocessedKeys. Réessayer immédiatement n'est pas optimal car cela pourrait aggraver le problème de limitation. Utiliser un AWS SDK est déjà implicite avec BatchGetItem et ne résout pas le problème sous-jacent. Augmenter la capacité d'écriture n'est pas pertinent pour les opérations de lecture comme BatchGetItem.