Aplikacja dewelopera używa funkcji AWS Lambda do przetwarzania wiadomości z kolejki Amazon SQS. Funkcja Lambda czasami kończy się niepowodzeniem lub przekracza limit czasu, a deweloper musi przechwycić i zbadać wiadomości, które nie mogły zostać przetworzone, przy najmniejszym nakładzie operacyjnym. Które podejście spełnia ten wymóg?

Poprawna odpowiedź to utworzenie kolejki martwych wiadomości (DLQ) i skonfigurowanie funkcji Lambda do wysyłania nieudanych wiadomości do tej DLQ. Jest to standardowy wzorzec obsługi błędów w systemach opartych na kolejkach, który zapewnia, że nieprzetworzone wiadomości są automatycznie przekazywane do dedykowanej kolejki w celu późniejszej analizy i ponownego przetworzenia. Minimalizuje to nakład operacyjny, ponieważ nie wymaga modyfikacji kodu funkcji Lambda do ręcznego zarządzania błędami. Zwiększenie limitu czasu funkcji Lambda do 15 minut może jedynie opóźnić błąd, a przeglądanie historii zdarzeń AWS CloudTrail nie jest przeznaczone do debugowania błędów aplikacji. Zwiększenie limitu czasu widoczności kolejki SQS nie rozwiąże problemu niepowodzeń funkcji Lambda, a sprawdzanie Amazon CloudWatch Logs wymaga aktywnego monitorowania i filtrowania. Utworzenie tabeli Amazon DynamoDB i aktualizacja funkcji Lambda w celu zapisywania nieudanych wiadomości jest możliwym rozwiązaniem, ale wymaga większego nakładu pracy na implementację i zarządzanie niż użycie DLQ.