Choose a message queue solution

  • 3 minutes

Storage queues and Service Bus queues have a slightly different feature set. You can choose either one or both, depending on the needs of your particular solution.

When determining which queuing technology fits the purpose of a given solution, solution architects and developers should consider these recommendations.

Consider using Service Bus queues

As a solution architect/developer, you should consider using Service Bus queues when:

  • Your solution needs to receive messages without having to poll the queue. With Service Bus, you can achieve it by using a long-polling receive operation using the TCP-based protocols that Service Bus supports.
  • Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
  • Your solution needs to support automatic duplicate detection.
  • You want your application to process messages as parallel long-running streams (messages are associated with a stream using the session ID property on the message). In this model, each node in the consuming application competes for streams, as opposed to messages. When a stream is given to a consuming node, the node can examine the state of the application stream state using transactions.
  • Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
  • Your application handles messages that can exceed 64 KB but won't likely approach the 256 KB or 1-MB limit, depending on the chosen service tier (although Service Bus queues can handle messages up to 100 MB).
  • You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers.

Consider using Storage queues

As a solution architect/developer, you should consider using Storage queues when:

  • Your application must store over 80 gigabytes of messages in a queue.
  • Your application wants to track progress for processing a message in the queue. It's useful if the worker processing a message crashes. Another worker can then use that information to continue from where the prior worker left off.
  • You require server side logs of all of the transactions executed against your queues.