Azure Service Bus (Queue & Topic) Overview

Introduction

Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics (in a namespace).

Service Bus is used to decouple applications and services from each other which help us to balance workload.

Service-bus consists of two main components i.e. 'Queue' & 'Topic – Subscription'.

Queue

As we can see in the below diagram, system can have multiple senders but only one message consumer receives and process each message.

Using queues to intermediate between message producers and consumers provides an inherent loose coupling between the components.

With Queues there are two different modes are available to process message with consideration of system.

Received & Delete

This mode is suitable where system can tolerate not processing messages in case of failure. In this mode, once consumer service read message it will be deleted from Queue irrespective of status of message process.

Peek

This mode is suitable where system cannot tolerate ignoring messages in case of failure. So here, messages are processed in two stages as below.

• Finds the next message to be consumed, locks it to prevent other consumers from receiving it, and then, return the message to the application.
• After the application finishes processing the message, it requests the Service Bus service to complete the second stage of the receive process. Then, the service marks the message as being consumed.

Topic - Subscription

As we can see in the below diagram, we do have 'Subscription' along with 'Topic' to process messages.

Senders send messages to a topic in the same way that they send messages to a queue, but it varies on a slight factor where 'Topics' can have multiple, independent 'Subscriptions'. Subscriptions are durable by default but can be configured to expire and then be automatically deleted.

We can define rules on a subscription. A subscription rule has a filter to define a condition for the message to be copied into the subscription and an optional action that can modify message metadata.

Quick Hands-on

In Azure Service bus, it has only three pricing tiers i.e. Basic, Standard & Premium. For this hands-on, we are using standard tier.

In Azure Service bus, only Premium tier has more network capability. Along with ‘VNET’ configuration, premium tier also supports ‘Availability zone’ and ‘Geo-DR’.

Like all other azure services, ‘Azure service bus’ also take care of encrypting data and it extended this feature to make use of ‘Customer-Managed’ key as well.

Let’s create queue, as we can see below it has many properties which need to be configured.

Max Queue Size

Total size of all entities in a namespace can't exceed this limit. Once max limit is reached then subsequent incoming messages will be rejected, and an exception will be received by the calling code.

Max Delivery count

There is a limit on number of attempts to deliver messages for Service Bus queues and subscriptions. When the delivery count exceeds the limit, the message is moved to the DLQ (dead-letter queue). Value ranging from 1 to 2000.

Message time to live

This is message expiry time.

Lock duration

Sets the amount of time that a message is locked for other receivers. After its lock expires, a message pulled by one receiver becomes available to be pulled by other receivers. Defaults to 30 seconds, with a maximum of 5 minutes.

Enable auto delete on idle queue

Delete the queue immediately after it remains idle for a configurable amount of time

Enable duplicate detection

Enabling duplicate detection configures your queue to keep a history of all messages sent to the queue for a configurable amount of time. During that interval, your queue will not accept any duplicate messages.

‘Service bus Explorer’ support to quick verification of queues and topics. It supports to send message into queues and topics as well as these messages can be read here.

This helps in quick verification of filters implemented on topics -subscription. For detailed information you can visit Microsoft article.

Let’s create ’Topic’ and ‘Subscription’. Topic has less configuration as compare to queue.

Once Topic is created, we can create ‘Subscription’ under topic. Subscription contains few common properties which we have seen in ‘Queue’

Once, Subscription is created we can configure filters on the Subscription and based on this rule data will be moved from topics to suitable subscription.

Here, we have created 4 subscriptions as below and on 2 subscriptions i.e. ‘sb_topic_homeessentialorder’ & ‘sb_topic_electronicorder’ filter is defined and other 2 subscriptions i.e. ‘sb_topic_defaultsubscription2’ & ‘sb_topic_defaultsubscription’ does not have any filters defined.

When we send message, which satisfies any rule then those messages will push to respective subscription and if that message does not satisfy any rule then it will go in all available subscription which does not have any rules.

Here, we are sending messages with text as ‘This is mobile order!’ and type we are passing as ‘electronic’.

Once message sent successfully, we can switch to ‘Receive’ tab and verify message. To verify message, we need to select subscription. We can see message come to ‘sb_topic_electronicorder’ and message count updated to ‘1’ whereas other subscription count remains ‘0’.

Now, we sent message without any type and observed that message is coming to both the subscriptions where no rules are defined 😊.

I hope this article will help you to understand end to end implementation of ‘Azure Service Bus – Queue & Topic’.

Thanks for reading this article. Please share your comments and review for the same.

Happy Coding 😊.