System obsługi zamówień sterowany zdarzeniami używa standardowej kolejki Amazon SQS. Podczas testowania przetwarzanie zatrzymało się, ponieważ pojedyncza wiadomość o zamówieniu spowodowała błąd backendu i zablokowała kolejne wiadomości. Limit czasu widoczności kolejki wynosi 30 sekund, podczas gdy przetwarzanie backendu przekracza limit czasu po 10 sekundach. Architekt rozwiązań musi umożliwić badanie wadliwych wiadomości i zapewnić dalsze przetwarzanie kolejnych wiadomości. Co powinien zrobić architekt rozwiązań?

Prawidłowa odpowiedź to utworzenie nowej standardowej kolejki SQS i skonfigurowanie jej jako kolejki martwych listów (DLQ) dla głównej kolejki. Gdy wiadomość nie może zostać przetworzona po określonej liczbie prób (redrive policy), jest ona automatycznie przenoszona do DLQ. Pozwala to na izolowanie problematycznych wiadomości i kontynuowanie przetwarzania kolejnych wiadomości w głównej kolejce. Architekt może później zbadać wiadomości w DLQ. Zwiększenie limitu czasu przetwarzania backendu do 30 sekund nie rozwiąże problemu z wadliwą wiadomością, która nadal będzie powodować błąd. Zmniejszenie limitu czasu widoczności SQS spowodowałoby szybsze ponowne pojawienie się wadliwej wiadomości w kolejce, co mogłoby pogorszyć problem, prowadząc do nieskończonej pętli przetwarzania. Użycie kolejki SQS FIFO jako DLQ jest niepotrzebne, ponieważ kolejność przetwarzania wadliwych wiadomości w DLQ zazwyczaj nie jest krytyczna, a standardowa kolejka jest bardziej elastyczna i tańsza.