Amazon SQS Polling Techniques | Short, Long & Web sockets.

 

Amazon SQS offers polling techniques to retrieve messages from queues. Each has different implications for cost, performance, and complexity.

Here's twtech breakdown of short polling, long polling, and the potential use of WebSockets (indirectly) with SQS.

 1. Short Polling:

➤ Concept:

Short polling is the default behavior when retrieving messages from SQS. It immediately returns a response, whether or not a message is available.

➤ Characteristics:

• Returns up to 10 messages (or fewer if none are available).
• May return empty responses even when messages exist (due to distributed architecture).
• Uses more API calls and thus higher cost.

➤ Use Case:

• When immediate response is necessary regardless of message availability.
• Low traffic queues.

 2. Long Polling:

➤ Concept:

Long polling waits up to 20 seconds for a message to arrive before responding. If a message becomes available, it returns immediately.

➤ Characteristics:

• Reduces number of empty responses and API calls.
• More cost-effective.
• Reduces client-side CPU/network usage.
• Can be set queue-wide or per ReceiveMessage call.

➤ Use Case:

• Recommended for most SQS use cases.
• When twtech wants to minimize polling cost and improve efficiency.

 3. WebSockets (Indirect Use):

 Amazon SQS does not natively support WebSockets.

However, twtech can simulate real-time message delivery using WebSockets in combination with SQS through other AWS services like:

➤ Architecture:

• SQS receives messages.
• AWS Lambda or EC2 service polls SQS (ideally with long polling).
• When a message is received, Lambda pushes the message to clients via:
• Amazon API Gateway (WebSocket API), or
• A WebSocket server hosted on EC2/ECS.

➤ Use Case:

• Real-time dashboards.
• Live alerts or notifications (e.g., trading apps, chat systems).
• Server push architecture with SQS as the buffer.

 Comparison Table:

Feature	Short Polling	Long Polling	WebSocket-based (Indirect)
Wait Time	Immediate	Up to 20 seconds	Real-time (pushed to client)
Cost	Higher	Lower	Depends on setup
Latency	High (if empty)	Low	Very low
Complexity	Low	Low	Higher (multi-service setup)
Use Case	Low-latency need	Efficient polling	Real-time delivery