AWS Serverless Error Handling With SQS as Event Source
Error Handling With AWS SQS as Event Source
If an Amazon SQS call fails or times out, the message is still visible.
The Lambda keeps retrying the message until it succeeds or the queue reaches its receive limit.
Setting up a dead-letter queue for rejected messages is a good practice.
Performance testing is required to find good solutions for your operations.
AWS SQS With Lambda
On Lambda functions, you can specify a timeout.
On SQS queues, you can define a visibility timeout.
You can also define the queue's batch size from one to ten messages per batch.
The batch size affects both your function and visibility timeout settings.
For quick processes, a larger batch size can increase efficiency.
For longer processes, a smaller batch size may be better.
Error Handling With AWS SQS as Event Source Video
W3schools.com collaborates with Amazon Web Services to deliver digital training content to our students.
How Error Handling With AWS SQS Works
If your function handles one message per 1 second, a batch of 10 messages will take 10 seconds to complete.
In that case, you could use 20 seconds timeout.
If a function handles one message per 2 minutes, the same batch will take 20 minutes to complete.
As Lambda's maximum timeout is 15 minutes, that batch would terminate without processing all messages.
Not processed messages would reappear in the queue.
Message Visibility
You must set the visibility timeout to provide your Lambda function enough time to complete a message batch.
When the function is throttled, you provide some buffer in the visibility timeout to accommodate Lambda call retries.
Setting your visibility timeout to 6 times the timeout of your function is recommended.
