Answer-first summary for fast verification
Answer: Increase the visibility timeout in the SQS queue to a value that is greater than the total of the function timeout and the batch window timeout.
## Explanation This issue occurs because SQS standard queues provide **at-least-once** delivery, which means messages can be delivered more than once. When a Lambda function processes messages from an SQS queue, it automatically deletes messages from the queue after successful processing. However, if the Lambda function fails or times out before completing processing, the message becomes visible again in the queue and can be reprocessed. **Key Concepts:** 1. **Visibility Timeout**: When a consumer receives a message from SQS, the message becomes invisible to other consumers for a period called the visibility timeout. If the message isn't deleted within this timeout period, it becomes visible again and can be processed by another consumer. 2. **Lambda Event Source Mapping**: When Lambda is configured with SQS as an event source, it automatically: - Polls the queue for messages - Invokes the Lambda function with batches of messages - Deletes messages from the queue after successful function execution **Why Option C is Correct:** Increasing the visibility timeout to a value greater than the total of the function timeout and batch window timeout ensures that: - The message remains invisible while the Lambda function is processing it - Even if the function takes longer than expected, the message won't become visible again prematurely - This prevents duplicate processing without requiring code changes or queue type changes **Why Other Options Are Not Optimal:** - **Option A**: Long polling reduces the number of empty responses but doesn't prevent duplicate message delivery. - **Option B**: Changing to FIFO queue would solve the issue (FIFO queues provide exactly-once processing), but this requires significant operational overhead: - Need to change queue type - Need to implement message deduplication IDs - FIFO queues have lower throughput limits - This is not the "LEAST operational overhead" solution - **Option D**: This would be problematic because: - Lambda automatically handles message deletion after successful processing - Deleting messages before processing could result in lost messages if processing fails - This requires code changes and introduces risk **Best Practice:** The recommended approach is to ensure the visibility timeout is at least 6 times the Lambda function timeout to account for retries and processing delays. This ensures messages aren't reprocessed while the function is still running or retrying.
Author: LeetQuiz Editorial Team
Ultimate access to all questions.
No comments yet.
An image-processing company has a web application that users use to upload images. The application uploads the images into an Amazon S3 bucket. The company has set up S3 event notifications to publish the object creation events to an Amazon Simple Queue Service (Amazon SQS) standard queue. The SQS queue serves as the event source for an AWS Lambda function that processes the images and sends the results to users through email.
Users report that they are receiving multiple email messages for every uploaded image. A solutions architect determines that SQS messages are invoking the Lambda function more than once, resulting in multiple email messages.
What should the solutions architect do to resolve this issue with the LEAST operational overhead?
A
Set up long polling in the SQS queue by increasing the ReceiveMessage wait time to 30 seconds.
B
Change the SQS standard queue to an SQS FIFO queue. Use the message deduplication ID to discard duplicate messages.
C
Increase the visibility timeout in the SQS queue to a value that is greater than the total of the function timeout and the batch window timeout.
D
Modify the Lambda function to delete each message from the SQS queue immediately after the message is read before processing.