Using an SQS queue between SNS and Lambda introduces some latency compared to invoking Lambda directly from SNS. Here are the main factors that contribute to latency:
- SQS polling interval – Lambda polls the SQS queue on a periodic interval, typically a few seconds. This means there will be at least a few second delay before Lambda picks up a new message from the queue.
- Batch size – Lambda processes messages from SQS in batches. It has to wait until it has enough messages to fill a batch before invoking the Lambda function. The bigger the batch size, the longer the delay.
- Batch window – If a batch window is configured, Lambda will wait up to that duration before invoking the function, even if the batch size is reached earlier. This adds more latency.
- Visibility timeout – When Lambda picks up a message from SQS, it remains invisible in the queue for the visibility timeout duration. This contributes to latency for that message.
- Propagation delay – It takes some time for a message to propagate from SNS to SQS. This adds a few milliseconds to seconds of delay.
- Network latency – The time for Lambda to make API calls to SQS also introduces some latency.
In contrast, when Lambda is invoked directly from SNS, there is minimal latency since the message is passed to Lambda immediately after it is published to the SNS topic.
So in summary, using SQS as an intermediary can introduce latency in the range of seconds to minutes, depending on the SQS and Lambda configuration. However, it also provides benefits like reprocessing of messages, better cost optimization and scaling. The trade-off is between latency and these other benefits.
No Comments