Standard queues support at-least-once message delivery. However, occasionally (because of the highly distributed architecture that allows nearly unlimited throughput), more than one copy of a message might be delivered out of order.
Standard queues support a nearly unlimited number of API calls per second, per API action (SendMessage, ReceiveMessage, or DeleteMessage).
Standard queues provide best-effort ordering which ensures that messages are generally delivered in the same order as they’re sent.
SQS Standard Queue Features
offers reliable and scalable hosted queues for storing messages
is engineered to always be available and deliver messages
provides the ability to store messages in a fail safe queue
highly concurrent access to messages
ensures delivery of each message at least once
stores copies of the messages on multiple servers for redundancy and high availability
might deliver duplicate copy of messages, if the servers storing a copy of a message is unavailable when you receive or delete the message and the copy of the message is not deleted on that unavailable server
Applications should be designed to be idempotent with the ability to handle duplicate messages and not be adversely affected if it processes the same message more than once
SQS messages can contain up to 10 metadata attributes.
take the form of name-type-value triples
can be used to separate the body of a message from the metadata that describes it.
helps process and store information with greater speed and efficiency because the applications don’t have to inspect an entire message before understanding how to process it
behavior of retrieving messages from the queue depends on whether short (standard) polling, the default behavior, or long polling is used
With short polling,
samples only a subset of the servers (based on a weighted random distribution) and returns messages from just those servers.
A receive request might not return all the messages in the queue. But a subsequent receive request would return the message
With Long polling,
request persists for the time specified and returns as soon as the message is available thereby reducing costs and time the message has to dwell in the queue
long polling doesn’t return a response until a message arrives in the message queue, or the long poll times out.
makes it inexpensive to retrieve messages from the SQS queue as soon as the messages are available.
might help reduce the cost of using SQS, as the number of empty receives are reduced
SQS allows send, receive and delete batching, which helps club up to 10 messages in a single batch while charging price for a single message
helps lower cost and also increases the throughput
Configurable settings per queue
All queues don’t have to be alike
makes a best effort to preserve order in messages does not guarantee first in, first out delivery of messages
can be handled by placing sequencing information within the message and performing the ordering on the client side
removes tight coupling between components
provides the ability to move data between distributed components of the applications that perform different tasks without losing messages or requiring each component to be always available
Multiple writers and readers
supports multiple readers and writers interacting with the same queue as the same time
locks the message during processing, using Visibility Timeout, preventing it to be processed by any other consumer
Variable message size
supports message in any format up to 256KB of text.
messages larger than 256 KB can be managed using the S3 or DynamoDB, with SQS holding a pointer to the S3 object
Access can be controlled for who can produce and consume messages to each queue
Delay queue allows the user to set a default delay on a queue such that delivery of all messages enqueued is postponed for that time duration
Dead Letter Queues
Dead letter queue is a queue for messages that were not able to be processed after a maximum number of attempts
useful to isolate messages that can’t be processed for later analysis.
supports the processing, storage, and transmission of credit card data by a merchant or service provider, and has been validated as being PCI-DSS (Payment Card Industry – Data Security Standard) compliant