Storage queues and Service Bus queues

This article compares and contrasts the two types of queues provided by Microsoft Azure: storage queues and service bus queues. You can make a more informed decision about which solution best meets your needs if you use this information.

Storage queues and Service Bus queues are the two types of queue mechanisms supported by Azure.

The Azure Storage infrastructure includes storage queues. They enable you to save a large number of messages. Authenticated HTTP or HTTPS calls allow you to access messages from anywhere in the world. A queue message can have a maximum size of 64 KB. A queue can hold millions of messages, up to the storage account's total capacity limit. Queues are frequently used to create a backlog of work that can be processed asynchronously.

Service Bus queues are a component of a larger Azure messaging infrastructure that includes queuing, publish/subscribe, and more advanced integration patterns. They are intended for the integration of applications or application components that may span multiple communication protocols, data contracts, trust domains, or network environments.

Considerations in Technology Selection

Storage queues and Service Bus queues have slightly different feature sets. You can select either one or both, depending on the requirements of your specific solution.

These recommendations should be considered by solution architects and developers when determining which queuing technology is best suited to the purpose of a given solution.

• Consider using Storage queues

Storage queues should be considered as a solution architect/developer when:

1. Your application must queue up to 80 gigabytes of messages.
2. Your application wishes to monitor the progress of a message in the queue. It's useful if the worker handling a message fails. The information can then be used by another worker to pick up where the previous worker left off.
3. All transactions executed against your queues must be logged on the server.

• Consider using Service Bus queues

You should consider using Service Bus queues as a solution architect/developer when:

1. Your solution must be able to receive messages without polling the queue. You can accomplish this with Service Bus by performing a long-polling receive operation using the TCP-based protocols that Service Bus supports.
2. Your solution necessitates that the queue guarantee first-in-first-out (FIFO) ordered delivery.
3. Your solution must be capable of detecting duplicates automatically
4. You want your application to process messages as long-running parallel streams (messages are associated with a stream using the session ID property on the message). Rather than competing for messages, each node in the consuming application competes for streams in this model. When a stream is passed to a consuming node, the node can use transactions to examine the state of the application stream.
5. When sending or receiving multiple messages from a queue, your solution requires transactional behavior and atomicity.
6. Your application handles messages that can exceed 64 KB but will most likely not exceed the 256 KB or 1 MB limits, depending on the service tier selected (although Service Bus queues can handle messages up to 100 MB).
7. You must provide a role-based access model to the queues, as well as different rights/permissions for senders and receivers.
8. Your queue size will not exceed 80 GB.
9. You want to use the standards-based messaging protocol AMQP 1.0.
10. You envision a transition from queue-based point-to-point communication to a publish-subscribe messaging pattern in the future. This pattern allows for the incorporation of additional receivers (subscribers). Each receiver receives independent copies of some or all messages queued.
11. Your messaging solution must support "At-Most-Once" and "At-Least-Once" delivery guarantees without requiring you to build additional infrastructure components.
12. Your solution must publish and consume messages in batches.