SQS (Amazon Simple Queue Service)
Component description
The Simple Queue Service is a message queue service. SQS enables messages to be sent, stored and received between software components of any size and quantity without message loss and without the need for additional services.
SQS brings automatic scaling to handle billions of messages per day. Because messages are stored geo-redundantly across multiple Availability Zones (AZs) in a region, messages are not lost if one AZ fails.
Variants
Standard queues
Standard queues support a nearly unlimited number of API calls per second, per API action (SendMessage, ReceiveMessage, or DeleteMessage). 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 provide best-effort ordering which ensures that messages are generally delivered in the same order as they're sent.
Message ordering: A standard queue makes a best effort to preserve the order of messages, but more than one copy of a message might be delivered out of order.
At-least-once delivery: Amazon SQS stores copies of your messages on multiple servers for redundancy and high availability. On rare occasions, one of the servers that stores a copy of a message might be unavailable when you receive or delete a message. If this occurs, the copy of the message isn't deleted on that unavailable server, and you might get that message copy again when you receive messages. Design your applications to be idempotent (they should not be affected adversely when processing the same message more than once).
FIFO queues
FIFO queues have all the capabilities of the standard queue. FIFO (First-In-First-Out) queues are designed to enhance messaging between applications when the order of operations and events is critical, or where duplicates can't be tolerated.
Message ordering: The order in which messages are sent and received is strictly preserved and a message is delivered once and remains available until a consumer processes and deletes it. Duplicates aren't introduced into the queue.
Exactly-once processing: FIFO queues don't introduce duplicate messages. If you retry the SendMessage action within the 5-minute deduplication interval, Amazon SQS doesn't introduce any duplicates into the queue.
Common use cases
Communication between microservices or distributed systems
asynchronous tasks like sending emails from an application
Distribution of tasks to worker nodes, e.g. processing of credit card validations
Planning of future tasks via batch messages, e.g. updating databases
Decouple real-time user requests from background tasks, such as uploading media as it is scaled and encoded
Optional features
Deadletter Queues
Amazon SQS supports dead-letter queues, which other queues (source queues) can target for messages that can't be processed (consumed) successfully. Dead-letter queues are useful for debugging your application or messaging system because they let you isolate problematic messages to determine why their processing doesn't succeed.
SNS Bridge
Amazon SQS supports SNS subscriptions, which act like a bridge between both services. By requesting this feature we create an additional SNS topic and subscribe the SQS queue to this topic. This is useful if your application can not interact on its own with SQS API.
Requesting Simple Queuing Service (SQS)
If you want to request Simple Queuing Service (SQS), you can do so by sending an E-Mail to service@root360.de or creating a ticket in the ticket system.
Required information
Required Information | Explanation | Options |
---|---|---|
Authentication | Both types of queues are provided with authentication. | A distinction is made between two types:
|
Name of Queue | Queues have to follow our naming pattern "<company>-<project>-<env>-<suffix>" with a maximum length of 80 characters (alphanumeric characters, hyphens, or underscores) | Select a name matching our naming pattern (for fifo queue add ".fifo") |
Fifo queue or standard queue | We can setup standard and fifo queues. | Standard queue, Fifo queue (default: Standard queue) |
Maximum message size | Maximal size of a single message. | min 1 Byte, max 262 144 Bytes (default: 262 144 Bytes) |
Message retention period | Amount of time that a message is stored in SQS. Older messages are deleted automatically. | min 1 day, max 4 days (default: 1 day) |
Receive message wait time | The receive message wait time is the maximum amount of time that polling will wait for messages to become available to receive | min 0 seconds, max 20 seconds (default: 0 seconds) |
Visibility timeout | Visibility timeout sets the length of time that a message received from a queue (by one consumer) will not be visible to the other message consumers | min 0 seconds, max 12 hours (default: 30 seconds) |
Delivery delay | The delivery delay is the amount of time to delay the first delivery of each message added to the queue. Any messages that you send to the queue remain invisible to consumers for the duration of the delay period. | min 0 seconds, max 15 minutes (default: 0 seconds) |
User access | In case you have/request multiple queues, we can either create one dedicated user per queue or grant access to multiple (please provide names of all queues/users) queues to one user. | Dedicated user per queue, master user for multiple queues |
Deadletter Qeue | Optional feature the allows you to utilize a dedicated DLQ per source queue. | true/false (default: false) |
Maximum receives | The Maximum receives value determines when a message will be sent to the DLQ. If the ReceiveCount for a message exceeds the maximum receive count for the queue, Amazon SQS moves the message to the associated DLQ (with its original message ID). | min 1 (default: false) Only applies if Deadletter Queue is requested. |
Pricing
For AWS pricing see https://aws.amazon.com/sqs/pricing/.
For root360 Managed Services pricing please contact our Service Team.
Related tutorials
intermediate
- 1 Component description
- 2 Variants
- 2.1 Standard queues
- 2.2 FIFO queues
- 3 Common use cases
- 3.1 Optional features
- 3.1.1 Deadletter Queues
- 3.1.2 SNS Bridge
- 3.1 Optional features
- 4 Requesting Simple Queuing Service (SQS)
- 4.1 Required information
- 4.1.1 Authentication
- 4.1.2 Name of Queue
- 4.1.3 Fifo queue or standard queue
- 4.1.4 Maximum message size
- 4.1.5 Message retention period
- 4.1.6 Receive message wait time
- 4.1.7 Visibility timeout
- 4.1.8 Delivery delay
- 4.1.9 User access
- 4.1.10 Deadletter Qeue
- 4.1.11 Maximum receives
- 4.1 Required information
- 5 Pricing
root360 Knowledge Base - This portal is hosted by Atlassian (atlassian.com | Privacy Policy)