Amazon SQS
Short vs Long Polling
Cut empty-receive cost and latency by waiting for messages instead of hammering the queue.
When a consumer calls ReceiveMessage, SQS can respond in two modes. Short polling (WaitTimeSeconds=0) queries a subset of servers and returns immediately, even if no messages are found — which means frequent empty responses, more API calls, and higher cost. Long polling (WaitTimeSeconds 1–20) tells SQS to wait up to that many seconds for a message to arrive before responding, querying all servers.
Short polling is repeatedly opening the fridge every few seconds to check for food — wasteful and you might miss the back shelf. Long polling is asking someone to tap you the moment food appears, up to 20 seconds — fewer trips, faster notice.
Key Concepts
1
Long polling is almost always preferred: it dramatically reduces the number of empty receives (and thus billed API requests), lowers latency (a message is returned as soon as it appears, not on the next poll), and reduces false-empty responses caused by SQS's distributed nature. AWS recommends enabling it nearly everywhere.
2
You set it per-receive with WaitTimeSeconds or as a queue default with ReceiveMessageWaitTimeSeconds.