Best practices for implementing partial batch responses (original) (raw)

The following are best practices for configuring partial batch responses for Amazon SQS event sources:

Note

Code-level performance tracking is required to track the overall performance of an application that uses partial batch processing. After partial batch processing is configured, Lambda function invocations almost always succeed, no matter what the result of the batch processing is.

Avoiding snowball anti-patterns

Lambda and Amazon SQS can’t control the messages that upstream microservices write to an Amazon SQS queue. If there are messages that can’t be processed, Lambda returns those unprocessed messages to the source Amazon SQS queue, unless a separate dead-letter queue is configured. Those unprocessed messages are then retried by the Lambda function in each following Amazon SQS message batch, fail, and return to the queue to be retried. If no dead-letter queue exists, the number of unprocessed messages returned to the Amazon SQS queue eventually outnumbers the valid messages in the queue.

This type of snowball anti-pattern—where each successive Lambda function invocation makes the problem worse—can cause the following issues:

To avoid creating a snowball anti-pattern when configuring partial batch responses in Amazon SQS, it’s a best practice to also create a dead-letter queue. This separate queue can store messages that aren’t processed successfully and help you better manage the lifecycle of your application’s unprocessed messages.

For instructions, see Configuring a dead-letter queue (console) in the Amazon SQS Developer Guide.