Amazon SQS Polling Techniques (Short, Long & Web Sockets) - Overview.
Scope:
- Intro,
- Short Polling,
- Long Polling,
- WebSockets (Indirect Use),
- Concept,
- Characteristics,
- Use Case,
- Comparison Table.
Intro:
- Amazon SQS offers polling techniques to retrieve messages from queues.
- Each polling techniques has different implications for cost, performance, and complexity.
Here's twtech Overview 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.
- Short polling 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.
- 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 |
No comments:
Post a Comment