Amazon Simple Queue Service is a simple, compelling service:

Amazon Simple Queue Service (Beta)

The Amazon Simple Queue Service offers a reliable, highly scalable hosted queue for buffering messages between distributed application components. The Amazon Simple Queue Service reduces the costs associated with resolving the producer-consumer problem that arises in distributed application development. Such costs include increased application development time, and potentially significant investment in server and network infrastructure to support distributed application messaging. Amazon has already invested in the large-scale computing infrastructure that runs the Queue Service, and since the Service’s interface is exposed via Web services, integration with applications is fast and easy.


Using the Amazon Simple Queue Service, you can decouple components of your application so that they run independently, with the Queue Service easing messaging management between components. Any component of a distributed application can store any type of data in a reliable queue at Amazon.com. Any other component or application can then later retrieve the data, using queue semantics. The queue acts as a buffer between the work-producer that is saving the data, and the work-consumer that is retrieving the data for processing. Thus, the queue resolves issues that would otherwise arise if the producer were producing work faster than the consumer can process the work, or if the producer or consumer were only intermittently connected to the network.


Registered developers have free access to the Simple Queue Service during the Beta, but storage is limited to 4,000 queue entries per developer.

Features

Basic Queue Operations


The Simple Queue Service employs a simple interface that is easy to use and highly flexible. The following operations are provided:



  • CreateQueue: Create queues for your own use, or to share with others.
  • ConfigureQueue: Modify the properties of an existing queue.
  • ListMyQueues: List your existing queues.
  • DeleteQueue: Delete one of your queues.
  • Enqueue: Add any data entries up to 4 KB in size to a specified queue.
  • Read: Return data from a specified queue. No data-key is required, and data is returned in roughly the same order it was added to the queue.
  • Dequeue: Remove a specified piece of data from a specified queue.

Specifically Designed for Use by Distributed Applications


A single queue can be used simultaneously by many distributed application components. There is no need for components to coordinate with each other to enable them to share a queue. A configurable read-lock feature is included to lower the incidence of duplicate messages when two applications are concurrently reading from the same queue.


Implemented to the Highest Standards for Performance and Reliability


The Amazon Simple Queue Service is built with the same stringent standards for performance and reliability as the rest of Amazon.com’s technology platform.

Intended Usage & Restrictions

  • The Amazon Simple Queue Service is designed for transitory storage of relatively small messages. A single entry placed in a queue cannot be larger than 4 KB in size, and cannot be left in the queue for more than 30 days (data left longer than this will be deleted).
  • During the Beta period, users of the Amazon Simple Queue Service are limited to storing up to 4,000 queue entries at a time in all queues created by the same subscription ID.
  • During the Beta period, there are limited security restrictions on access to individual queues. Access is granted to another user or application if they can provide your AWS Subscription ID and the corresponding identifier of your queue.
  • Applications should be prepared for the event where the same message is read more than once from the queue. In particular: A message may be returned by Read even though it has already been dequeued; and concurrent Read calls may return the same message to multiple readers. This behavior is a result of prioritizing reliable data storage (even in the face of hardware failures), and we expect such events to occur very infrequently. One way applications can cope with these occasional duplicates is by making the messages stored in the queue idempotent – that is, by ensuring that the effect of repeated receipt of a message is the same as that of receiving it once.