SQS long & short polling

By default, SQS uses short polling.

---

Short Polling

• When an EC2 instance requests messages, SQS checks only a subset of the servers for available messages.
• This is done quickly, so it responds immediately.
• Advantage → faster response.
• Disadvantage → may return empty responses even if messages exist (because not all servers were checked).
• Default setting: ReceiveMessageWaitTimeSeconds = 0.

Example:
Think of checking a few lanes in a highway instead of all lanes — you might miss a car (message).

---

Long Polling

• SQS waits for a set amount of time before returning a response.
• It checks more thoroughly to see if messages are available.
• This reduces empty responses and unnecessary requests.
• Saves costs because fewer API calls are made.
• Controlled by ReceiveMessageWaitTimeSeconds attribute.
• Setting it to a value > 0 (up to 20 seconds) enables long polling.

Example:
Like waiting a little longer before checking lanes to ensure you catch any incoming cars.

---

2. How ReceiveMessageWaitTimeSeconds Works

• Default: 0 seconds → short polling.
• Greater than 0: long polling.
• For example, setting it to 10 seconds means: When the application polls the queue, it will wait up to 10 seconds to see if a message becomes available before returning.

---

Why long polling reduces cost:

• Short polling can return empty responses → EC2 instances keep making more requests → more API calls → higher cost.
• Long polling reduces empty responses → fewer requests → cost savings.

---

💡 Key takeaway:
By setting ReceiveMessageWaitTimeSeconds to a number greater than 0, you switch from short polling to long polling — making message retrieval more efficient and reducing costs.