Une entreprise dispose d'un flux de travail d'ingestion de données composé d'une rubrique Amazon SNS qui reçoit des notifications concernant les nouvelles livraisons de données et d'une fonction AWS Lambda qui traite et stocke les données. Occasionnellement, l'ingestion échoue en raison de problèmes de connectivité réseau, et ces données ne sont pas ingérées à moins qu'un travail ne soit relancé manuellement. Que doit faire un architecte de solutions pour s'assurer que toutes les notifications sont finalement traitées ?

La configuration d'une file d'attente Amazon SQS comme destination en cas d'échec (Dead-Letter Queue ou DLQ) pour la fonction Lambda garantit que les messages qui échouent lors du traitement initial sont conservés et peuvent être traités ultérieurement. Cela permet de récupérer les données qui n'ont pas pu être ingérées en raison de problèmes temporaires, comme des problèmes de connectivité réseau, sans intervention manuelle immédiate. La fonction Lambda peut ensuite être modifiée pour traiter les messages de cette file d'attente, assurant ainsi un traitement éventuel de toutes les notifications. Augmenter les allocations de CPU et de mémoire peut améliorer les performances mais ne résout pas les échecs liés à la connectivité réseau. Configurer la fonction Lambda pour un déploiement sur plusieurs zones de disponibilité améliore la résilience de la fonction elle-même, mais ne gère pas les échecs de traitement des messages individuels. Configurer la stratégie de nouvelle tentative de la rubrique SNS n'est pas la solution idéale car SNS n'est pas conçu pour la persistance des messages en cas d'échec de traitement par le consommateur.