What should the solutions architect do to resolve this issue with the LEAST operational overhead?
Set up long polling in the SQS queue by increasing the ReceiveMessage wait time to 30 seconds.
Change the SQS standard queue to an SQS FIFO queue. Use the message deduplication ID to discard duplicate messages.
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.
Modify the Lambda function to delete each message from the SQS queue immediately after the message is read before processing.
Explanations:
Long polling helps reduce the number of empty responses, but it does not directly address the issue of Lambda function invocation more than once due to multiple SQS messages being sent. The problem is related to duplicate invocations, not the polling mechanism itself.
Changing to a FIFO queue does not resolve the issue of multiple invocations of the Lambda function. While FIFO queues ensure message ordering and deduplication, the root issue is that the SQS messages might be processed multiple times due to improper handling of Lambda’s acknowledgment.
Increasing the visibility timeout ensures that a message remains invisible to other Lambda instances while it’s being processed. This prevents multiple invocations of the Lambda function for the same message, resolving the issue of duplicate emails being sent.
Modifying the Lambda function to delete messages before processing could lead to data loss if the function fails during processing. The correct approach is to let Lambda acknowledge message processing after successful execution, avoiding duplicate message processing.
My best guess is:
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.
I plot that the answer is:
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.