Amazon SQS

Distributed queues

There are three main parts in a distributed messaging system: the components of your distributed system, your queue (distributed on Amazon SQS servers), and the messages in the queue.

In the following scenario, your system has several producers (components that send messages to the queue) and consumers (components that receive messages from the queue). The queue (which holds messages A through E) redundantly stores the messages across multiple Amazon SQS servers.

Message lifecycle

The following scenario describes the lifecycle of an Amazon SQS message in a queue, from creation to deletion.

A producer (component 1) sends message A to a queue, and the message is distributed across the Amazon SQS servers redundantly.

When a consumer (component 2) is ready to process messages, it consumes messages from the queue, and message A is returned. While message A is being processed, it remains in the queue and isn't returned to subsequent receive requests for the duration of the visibility timeout.

The consumer (component 2) deletes message A from the queue to prevent the message from being received and processed again when the visibility timeout expires.

Amazon SQS supports two types of queues – standard queues and FIFO queues. Use the information from the following table to chose the right queue for your situation. To learn more about Amazon SQS queues, see Amazon SQS Standard queues and Amazon SQS FIFO (First-In-First-Out) queues.

Standard queues	FIFO queues
Unlimited Throughput – Standard queues support a nearly unlimited number of API calls per second, per API action (SendMessage, ReceiveMessage, or DeleteMessage). At-Least-Once Delivery – A message is delivered at least once, but occasionally more than one copy of a message is delivered. Best-Effort Ordering – Occasionally, messages are delivered in an order different from which they were sent.	High Throughput – If you use batching, FIFO queues support up to 3,000 calls per second, per API method (SendMessageBatch, ReceiveMessage, or DeleteMessageBatch). The 3,000 calls per second represent 300 API calls, each with a batch of 10 messages. To request a quota increase, submit a support request. Without batching, FIFO queues support up to 300 API calls per second, per API method (SendMessage, ReceiveMessage, or DeleteMessage). Exactly-Once Processing – A message is delivered once and remains available until a consumer processes and deletes it. Duplicates aren't introduced into the queue. First-In-First-Out Delivery – The order in which messages are sent and received is strictly preserved.
Send data between applications when the throughput is important, for example: Decouple live user requests from intensive background work: let users upload media while resizing or encoding it. Allocate tasks to multiple worker nodes: process a high number of credit card validation requests. Batch messages for future processing: schedule multiple entries to be added to a database.	Send data between applications when the order of events is important, for example: Make sure that user-entered commands are run in the right order. Display the correct product price by sending price modifications in the right order. Prevent a student from enrolling in a course before registering for an account.