How should the Solutions Architect meet these requirements?
Receive multiple messages with each Lambda invocation, add error handling to message processing code and delete messages after processing, increase the visibility timeout for the messages, create a dead letter queue for messages that could not be processed, create an Amazon CloudWatch alarm on Lambda errors for notification.
Receive single messages with each Lambda invocation, put additional Lambda workers to poll the queue, delete messages after processing, increase the message timer for the messages, use Amazon CloudWatch Logs for messages that could not be processed, create a CloudWatch alarm on Lambda errors for notification.
Receive multiple messages with each Lambda invocation, use long polling when receiving the messages, log the errors from the message processing code using Amazon CloudWatch Logs, create a dead letter queue with AWS Lambda to capture failed invocations, create CloudWatch events on Lambda errors for notification.
Receive multiple messages with each Lambda invocation, add error handling to message processing code and delete messages after processing, increase the visibility timeout for the messages, create a delay queue for messages that could not be processed, create an Amazon CloudWatch metric on Lambda errors for notification.
Explanations:
This option correctly handles multiple messages in a single Lambda invocation, implements error handling to manage failed messages, deletes messages only after successful processing, increases visibility timeout to allow for message reprocessing, and uses a dead letter queue to retain problematic orders. Additionally, it sets up a CloudWatch alarm to notify when Lambda errors exceed a specified threshold, meeting all the resiliency requirements.
While this option receives single messages with each Lambda invocation, it does not address the need for handling message failures effectively. It suggests increasing the message timer, which is not applicable in SQS. Additionally, using CloudWatch Logs instead of a dead letter queue does not meet the requirement to retain problematic orders for analysis.
This option includes several correct elements like receiving multiple messages and using long polling, but it lacks a mechanism to delete messages after successful processing. Logging errors using CloudWatch Logs is insufficient for retaining problematic orders. While it mentions a dead letter queue, the setup of CloudWatch events for notification is less effective than using an alarm to monitor error thresholds.
Although this option suggests receiving multiple messages and includes some correct elements like error handling and message deletion after processing, it incorrectly suggests creating a delay queue instead of a dead letter queue for failed messages. A delay queue does not retain problematic orders for analysis. Additionally, using a CloudWatch metric for notification is less effective than an alarm for tracking error thresholds.
I draft that the answer is:
Receive multiple messages with each Lambda invocation, add error handling to message processing code and delete messages after processing, increase the visibility timeout for the messages, create a dead letter queue for messages that could not be processed, create an Amazon CloudWatch alarm on Lambda errors for notification.
To the best of my knowledge, the answer is:
Receive multiple messages with each Lambda invocation, add error handling to message processing code and delete messages after processing, increase the visibility timeout for the messages, create a dead letter queue for messages that could not be processed, create an Amazon CloudWatch alarm on Lambda errors for notification.