What's the difference between the SQS batch window duration and ReceiveMessage wait time seconds?

They're fundamentally different.

The receive message wait time setting is a setting that determines if your application will be doing long or short polling. You should (almost) always opt for long polling as it helps reduce your costs; the how is in the documentation.

It can be set in 2 different ways:

on the queue level, by setting the ReceiveMessageWaitTimeSeconds attribute
on the message level, by setting the WaitTimeSeconds property on your ReceiveMessage calls

It determines how long your application will wait for a message to become available in the queue before returning an empty result.

On the other hand, you can configure an SQS queue as an event source for Lambda functions by adding it as a trigger.

When creating an SQS trigger, you have 2 optional fields:

batch size (the number of messages in each batch to send to the function)
batch window (the maximum amount of time to gather SQS messages before invoking the function, in seconds)

The batch window function sets the MaximumBatchingWindowInSeconds attribute for SQS event source mapping.

It's the maximum amount of time, in seconds, that the Lambda poller waits to gather the messages from the queue before invoking the function. The batch window just ensures that more messages have accumulated in the SQS queue before the Lambda function is invoked. This increases the efficiency and reduces the frequency of Lambda invocations, helping you reduce costs.

It's important to note that it's defined as the maximum as it's not guaranteed.

As per the docs, your Lambda function may be invoked as soon as any of the below are true:

the batch size limit has been reached
the batching window has expired
the batch reaches the payload limit of 6 MB

To conclude, both features are used to control how long something waits but the resulting behaviour differs.

In the first case, you're controlling how long the poller (your application) could wait before it detects a message in your SQS queue & then immediately returns. You could set this value to 10 seconds but if a message is detected on the queue after 5 seconds, the call will return. You can change this value per message, or have a universal value set at the queue level. You can take advantage of long (or short) polling with or without Lambda functions, as it's available via the AWS API, console, CLI and any official SDK.

In the second case, you're controlling how long the poller (inbuilt Lambda poller) could wait before actually invoking your Lambda to process the messages. You could set this value to 10 second and even if a message is detected on the queue after 5 seconds, it may still not invoke your Lambda. Actual behaviour as to when your function is invoked, will differ based on batch size & payload limits. This value is naturally set at the Lambda level & not per message. This option is only available when using Lambda functions.

You can’t use both together as long/short polling is for a constantly running application or one-off calls. A Lambda function cannot poll SQS for more than 15 minutes and that is with a manual invocation.

For Lambda functions, you would use native SQS event sourcing and for any other service/application/use case, you would manually integrate SQS.

They're same in the sense that both aim to help you to ultimately reduce costs, but very different in terms of where you can use them.

Recommended topics

Hot tags