SQS
fully managed message queuing service
Last updated
fully managed message queuing service
Last updated
AWS Document | Workshop | FAQs |
fully managed message queuing service
provide way for asynchronously communicate between applications, without loosing messages
How? It stores the copies of messages redundantly across multi-AZ.
decouple and scale microservices, distributed system and serverless applications.
Dead-letter queue (DLQ): contains messages that could not be processed.
default polling setting.
WaitTimeSeconds
= 0. Messages are returned immediately.
ReceiveMessageWaitTimeSeconds
: when the wait time of ReceiveMessage
API > 0, long polling are in effect. Long polling help reduce empty responses.
WaitTimeSeconds
> 0
Maximum wait time: 20 secs
VisibilityTimeout
: after a message is received, it still remains in the queue. The length of time which a message unavailable after delivering. To stop other consumers from processing that message again -> set visibility timeout
on the ReceiveMessage
API call to beyond what the longest transaction takes to process.
Default: 30 seconds. Min is 0 sec, Max is 12 hours.
Increase VisibilityTimeout
if a consumer received message more than one.
MessageRetentionPeriod
: seconds that SQS will keep the message. Default is 4 days.
DelaySeconds
: seconds for which the delivery of all messages is delayed. Default is 0 second.
Eliminate administrative overhead.
Keep sensitive data secure. Refer encryption.
Reliability delivery messages
Scale elastically and cost-effectively.
Redundantly stores messages across multiple servers.
Automatically scale
Built-in encryption, access control features
Message locking: when a message received, it is locked for processing.
When completed, it deletes the message from the queue.
When failed, the lock expire -> the message is available again.
Queue sharing: queue can be shared anonymously or to specific AWS accounts.
Throughput
unlimited
3000 msg/sec
Delivery type
Best-effort ordering (out of order)
FIFO
Duplicate?
Yes
No (exactly-once send) built-in deduplication and ordering capabilities.
Ordering
No
Yes
In-flight encryption: HTTPS API
At rest encryption: KMS keys
Client-side encryption
Server-side encryption (SSE): encrypt each message body
Similar to S3 bucket policies
Useful for cross-account access to SQS queues.
Use batching: sending messages in batch can improve performance and reduce costs.
Setting appropriate visibility timeouts
Monitor your queues.
Cannot change the queue type (Standard -> FIFO or FIFO -> Standard) after you create the queue.
Message is persisted in SQS until a consumer deletes it.
Message retention
: default 4 days, up to 14 days.
When need a solution with decoup or performance improvement by distribute load, use SQS.