Choose between Azure Queue services – Queue Storage, Service Bus Queue, Service Bus Topics

Suppose you are planning the architecture for your music-sharing application. You want to ensure that music files are uploaded to the web api reliably from the mobile app. we then want to deliver the details about new songs directly to the app when an artist adds new music to their collection. This is a perfect use of a message-based system and Azure offers three solutions to this problem:

  • Azure Queue Storage
  • Azure Service Bus Queue
  • Azure Service Bus Topics

Each has a slightly different feature set, which means you can choose one or the other, or use both, depending on the problem you are solving.

Choose Service Bus Topics if

you need multiple receivers to handle each message

Choose Service Bus queues if

You need an At-Most-Once delivery guarantee.
You need a FIFO guarantee.
You need to group messages into transactions.
You want to receive messages without polling the queue.
You need to provide a role-based access model to the queues.
You need to handle messages larger than 64 KB but less than 256 KB.
Your queue size will not grow larger than 80 GB.
You would like to be able to publish and consume batches of messages.

Queue storage isn’t quite as feature-rich, but if you don’t need any of those features, it can be a simpler choice. In addition, it’s the best solution if your app has any of the following requirements.

Choose Queue storage if

You need an audit trail of all messages that pass through the queue.
You expect the queue to exceed 80 GB in size.
You want to track progress for processing a message inside of the queue.

A queue is a simple, temporary storage location for messages sent between the components of a distributed application. Use a queue to organize messages and gracefully handle unpredictable surges in demand.


Use Storage queues when you want a simple and easy-to-code queue system. For more advanced needs, use Service Bus queues. If you have multiple destinations for a single message, but need queue-like behavior, use topics.

I hope this will help !!!

NOTE — Reference taken from Microsoft Learning Site

Azure Service Bus Sessions

Azure Service Bus sessions enable joint and ordered handling of unbounded sequences of related messages. Sessions can be used when you want to maintain order of messages at receiver.

The basic tier of Service Bus doesn’t support sessions. The standard and premium tiers support sessions.

On session-aware queues or subscriptions, sessions come into existence when there’s at least one message with the session’s SessionId. Once a session exists, there’s no defined time or API for when the session expires or disappears. Theoretically, a message can be received for a session today, the next message in a year’s time, and if the SessionId matches, the session is the same from the Service Bus perspective.

Concurrent de-multiplexing using session

Sessions provide concurrent de-multiplexing of interleaved message streams while preserving and guaranteeing ordered delivery.

Consider a scenario, where 3 different clients are sending messages to Service Bus Queue concurrently with a unique Identifier corresponding to each client and at the receiving end, interleaved messages from each client should be received by different receivers.

FIFO Queue

When you want to deliver the messages in the same order as they are pushed in the queue. we need to send messages into session enabled queue with unique SessionId(Guid).

Queue Icons - Download Free Vector Icons | Noun Project

This will enable our Message Session Handler to read messages from queue by following First In, First Out Pattern.

How to enable session in service bus?

You can enable session on azure portal by setting the “Enable sessions” flag. This is applicable to both Queues and Topic Subscriptions.

When Sessions are enabled on a queue or a subscription, the client applications can no longer send/receive regular messages. All messages must be sent as part of a session (by setting the session id) and received by receiving the session.

Alternatively, The session enabled Azure Service Bus Queue can be created by setting the “RequireSession” property to true, using Windows Azure Service Bus library in .Net client.

How to send messages to session enabled service bus?

Sending messages to session enabled Service Bus entities is little different from entities in which session is not enabled. It is mandatory to set SessionId property in every message that is being sent.

Session are set on each message by setting a SessionId property of the brokered message. Its simple whichever message you want to be part of same session just set the same session id for them. For demo purpose, I am just setting the sessions to even and odd based on the counter.

How to receive messages from session enabled service bus?

There are multiple ways to handle session messages but in my example I will use a session handler which I feel is the most elegant way to read messages from session queue.

Register the message session handler which we will use to read the messages from session queue.


Imagine a huge stream of messages with different sessionIds. You can clearly understand how sessions can help us de-multiplexing a stream of messages.

It is also simple to implement concurrent processing for sessions. If you notice the code snippet I pasted above for Read Message With Session Handler method has a property called MaxConcurrentSessions which is currently set to 1. We can simply change this and you would see that your sessions are processed concurrently.

Source Code

Source code for this article is available at GitHub.


I hope this will help you when you want to design application where you want to maintain ordering of messages while you read messages from queue.