The Polling Problem
SQS is a pull-based system — consumers must ask SQS "do you have any messages for me?" This is called polling. How you poll has a significant impact on cost and latency.
Short Polling (The Default, and Usually Wrong)
With short polling, SQS queries only a subset of its servers and returns immediately — even if the queue is empty. If no messages are found, the consumer gets an empty response and must poll again.
- Problem 1 — Cost: If your queue is often empty, you're making thousands of API calls per hour that return nothing. SQS charges per API call.
- Problem 2 — Latency: You might miss messages that are sitting on servers that weren't queried in that particular poll.
Long Polling (The Correct Default for Most Cases)
With long polling, SQS holds the connection open for up to 20 seconds, waiting for a message to arrive. If a message arrives during that window, it's returned immediately. If no message arrives after 20 seconds, SQS returns an empty response.
Configure long polling by setting WaitTimeSeconds to a value between 1 and 20 when calling ReceiveMessage, or set it at the queue level via the ReceiveMessageWaitTimeSeconds attribute.
Benefits:
- Reduces cost: Fewer empty API calls.
- Reduces latency: Messages are returned the moment they arrive, not on the next poll cycle.
- Eliminates false empties: Long polling queries all SQS servers, so you won't miss messages due to partial server queries.
The only reason to use short polling is if your application requires an immediate response even when the queue is empty — which is rare.