Right, so at a minimum if you aren’t sending more than 10 messages you’ll have a wait time of at least 2 seconds, since that’s the batch timeout. The other delays you mentioned of up to 20 seconds sound a lot like the max value for the SQS wait_time_seconds option. You aren’t setting it explicitly, but the queue itself will also have a default. What is the queues ReceiveMessageWaitTimeSeconds value?

We have observed the same thing, especially when we only have 1 or 2 messages being sent to the queue every now and then.

For us the issue was broadwaySQS’s default polling (short polling) and receive_interval (5 seconds).
The default behaviour sees a broadway producer polling sqs for messages and on an empty receive, waiting 5 seconds before trying again.

If there are very few messages in the queue short polling does not guarantee you will get any messages since it only queries a subset of the servers that make up your SQS queue. That means it can take multiple attempts to get a single message. In our case, that meant our broadway producer would take between 2 and 60 seconds to receive a message when there was only 1 enqueued.

We needed the best response time possible and were able to achieve it by reducing the receive_interval to 50 ms and setting the wait_time_seconds to 20.
Note: for receive_interval doesn’t seem necessary with long polling and we wanted the value close to 0, but it would probably work with 0.
for wait_time_seconds: any number above 0 enables long polling SQS long polling docs. Long polling is guaranteed to not return an empty receive if there are any messages in the queue and it will return as soon as any messages are available.

For example:

producer: [
        module: {
          BroadwaySQS.Producer,
          queue_url: Keyword.get(config, :queue_url), config: Keyword.get(config, :credentials), 
          wait_time_seconds: 20
          receive_interval: 50
        },
      ],