Funkcja Lambda przetwarza wiadomości ze standardowej kolejki Amazon SQS (rozmiar partii 10) i zapisuje wyniki do S3. Pierwszego dnia, napływ wiadomości przewyższa możliwości przetwarzania, a wiele wiadomości w kolejce zawiera nieprawidłowe dane, co powoduje, że prawidłowe wiadomości nie są przetwarzane w wymaganym terminie. Która zmiana zapewni, że prawidłowe wiadomości zostaną przetworzone na czas?

Poprawna odpowiedź rozwiązuje problem nieprzetwarzania poprawnych wiadomości. Pozostawienie rozmiaru partii bez zmian jest rozsądne, ponieważ zwiększenie go mogłoby pogorszyć problem z błędnymi wiadomościami. Kluczowe jest skonfigurowanie funkcji Lambda tak, aby zgłaszała nieudane elementy partii. Dzięki temu tylko te konkretne, błędne wiadomości wrócą do kolejki, a nie cała partia, co pozwoli na dalsze przetwarzanie poprawnych wiadomości. Konfiguracja kolejki SQS dead-letter queue (DLQ) jest niezbędna do przechwytywania uporczywie błędnych wiadomości, zapobiegając ich blokowaniu głównej kolejki i umożliwiając ich analizę lub ponowne przetworzenie poza głównym strumieniem. Pozostałe opcje są mniej skuteczne: Zwiększenie rozmiaru partii Lambda mogłoby pogorszyć problem, ponieważ więcej poprawnych wiadomości byłoby blokowanych przez pojedyncze błędne wiadomości w większej partii. Zmniejszenie rozmiaru partii Lambda mogłoby spowolnić przetwarzanie, a zwiększenie limitu przepustowości SQS nie rozwiąże problemu błędnych wiadomości. Włączenie S3 Transfer Acceleration jest nieistotne dla problemu z przetwarzaniem wiadomości SQS.