Firma posiada mechanizm pozyskiwania danych składający się z tematu Amazon SNS, który odbiera powiadomienia o nowych dostawach danych, oraz funkcji AWS Lambda, która przetwarza i przechowuje dane. Czasami pozyskiwanie danych kończy się niepowodzeniem z powodu problemów z łącznością sieciową, a dane te nie są pozyskiwane, chyba że zadanie zostanie ręcznie uruchomione ponownie. Co powinien zrobić architekt rozwiązań, aby zapewnić, że wszystkie powiadomienia zostaną ostatecznie przetworzone?

Poprawna odpowiedź to skonfigurowanie kolejki Amazon SQS jako miejsca docelowego w przypadku niepowodzenia (Dead-Letter Queue – DLQ) dla funkcji Lambda. Gdy funkcja Lambda nie przetworzy wiadomości (np. z powodu problemów z łącznością), wiadomość zostanie automatycznie przeniesiona do kolejki SQS. Następnie funkcja Lambda może zostać zmodyfikowana tak, aby przetwarzała wiadomości z tej kolejki, zapewniając, że żadne dane nie zostaną utracone i wszystkie powiadomienia zostaną ostatecznie przetworzone. Pozostałe opcje są mniej skuteczne: Wdrożenie funkcji Lambda w wielu strefach dostępności zwiększa odporność na awarie stref, ale nie rozwiązuje problemów z przetwarzaniem wiadomości, które już się nie powiodły. Zwiększenie alokacji CPU i pamięci dla funkcji Lambda może pomóc w przypadku problemów z wydajnością, ale nie rozwiąże problemów z łącznością sieciową ani nie zapewni ponownego przetworzenia nieudanych wiadomości. Konfiguracja strategii ponawiania tematu SNS nie jest bezpośrednio związana z ponownym przetwarzaniem wiadomości, które nie zostały przetworzone przez funkcję Lambda; SNS dostarcza wiadomości do subskrybentów, ale nie zarządza logiką ponawiania po stronie funkcji Lambda.