A DevOps engineer is building a solution that uses Amazon Simple Queue Service (Amazon SQS) standard queues. The solution also includes an AWS Lambda function and an Amazon DynamoDB table. The Lambda function pulls content from an SQS queue event source and writes the content to the DynamoDB table.
The solution must maximize the scalability of Lambda and must prevent successfully processed SQS messages from being processed multiple times.
Which solution will meet these requirements?
To prevent successfully processed SQS messages from being processed multiple times while maximizing the scalability of the Lambda function, you should include the ReportBatchItemFailures value in the FunctionResponseTypes list when configuring the Lambda function's event source mapping. This configuration enables partial batch responses, allowing only the messages that failed processing to be visible again in the queue, thus reducing the number of unnecessary retries and eliminating the possibility of duplicate processing for successfully processed messages.
It's C, here is a reference: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#services-sqs-batchfailurereporting
link updated: https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-errorhandling.html
Lambda process messages in batches. If one message in the batch fails the whole batch considered failed and all messages in the batch return to the queue. For example if batch has 10 messages and message 5 and 7 failed to get processed, all 10 messages will return to the queue. So, successfully processed messages can get processed again. Now to prevent this to happen you have two ways (used to be one) 1. Write your code in a way to identify processed messages and delete them manually from SQS. 2. Partial batch response that returns only the messages that were failed to be processed (supported since Dec 2021). References: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#services-sqs-batchfailurereporting
To avoid reprocessing successfully processed messages in a failed batch, you can configure your event source mapping to make only the failed messages visible again. This is called a partial batch response. To turn on partial batch responses, specify ReportBatchItemFailures for the FunctionResponseTypes action when configuring your event source mapping. This lets your function return a partial success, which can help reduce the number of unnecessary retries on records. https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#services-sqs-batchfailurereporting
C is correct. We need ReportBatchItemFailures to return only failed items A: batch window is the interval process time B: batch size is the size of the job D: queue visibility timeout is about re-process
answer C
https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#services-sqs-batchfailurereporting
https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#services-sqs-batchfailurereporting
"Implementing partial batch responses When "Lambda function encounters an error while processing a batch, all messages"... "become visible in the queue"... "including messages that Lambda processed successfully." "...your function can end up processing the same message several times. "To avoid reprocessing successfully processed messages in a failed batch" "configure your event source mapping to make only the failed messages visible again." "To turn on partial batch responses, specify ReportBatchItemFailures for the FunctionResponseTypes action when configuring your event source mapping." "This lets your function return a partial success, which can help reduce the number of unnecessary retries on records." https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-errorhandling.html
The URL with "services-sqs-batchfailurereporting" pointer seems to be invalid now. I think the preceeding URL replaced it.
C doesn't address the "maximize the scalability of Lambda" while B addresses both, while batch size is 1, you either fail or success
C is correct.
B is correct