Un système de commande basé sur les événements utilise une file d'attente standard Amazon SQS. Pendant les tests, le traitement s'est arrêté car un seul message de commande a provoqué une erreur backend et a bloqué les messages suivants. Le délai de visibilité de la file d'attente est de 30 secondes, tandis que le traitement backend expire après 10 secondes. Un architecte de solutions doit permettre l'investigation des messages défectueux et s'assurer que les messages suivants continuent d'être traités. Que doit faire l'architecte de solutions ?

La création d'une file d'attente de lettres mortes (DLQ) SQS standard est la solution la plus appropriée. Lorsqu'un message échoue à être traité après un nombre spécifié de tentatives (redrive policy), il est automatiquement déplacé vers la DLQ. Cela permet aux messages suivants d'être traités sans être bloqués par le message défectueux, et la DLQ fournit un emplacement centralisé pour enquêter sur les messages ayant échoué. Une file d'attente SQS FIFO n'est pas nécessaire ici car le problème n'est pas lié à l'ordre des messages, et une file d'attente standard est suffisante pour une DLQ. Augmenter le délai d'expiration du traitement backend ne résoudrait pas le problème sous-jacent du message défectueux et pourrait même aggraver la situation en bloquant le traitement plus longtemps. Réduire le délai de visibilité SQS entraînerait la remise en file d'attente plus rapide du message défectueux, ce qui pourrait potentiellement créer une boucle infinie de tentatives de traitement infructueuses.