Azure Service Bus Features Sending The Right Message: A Guide To Azure Service Bus Features

In my last blog post, I wrote about Azure Service Bus and briefly explained how it works. Today, I will delve deeper into the topic and describe some of its more advanced features.

First things first, though. As I promised you last time, here is some information about the pricing tiers. Azure Service Bus is available in three options: Basic, Standard, and Premium. Here is a table which highlights the differences:

Pricing options for Azure Service Bus

At first look, we can see that there are many differences between the first two tiers. On the other hand, Standard and Premium look very similar. However, the devil is in the detail, and later I will come back to this topic to explain the differences.

Transactions

The first feature to cover is a transaction which forms an execution scope in the context of transaction processing. A single transaction groups two or more operations with the aim of them having a common outcome.

A transaction coordinator or a transaction framework, therefore, ensures that the operations belonging to a single group either jointly fail or jointly succeed. In this respect, they “act as one”[1], which is referred to as atomicity.

We can use transaction to maintain integrity of internal operations against its message stores. It means that you can build a system based on messages and you can be assured that your functions will be fully processed.

The entire asynchronous messaging process will be completed, or everything will be rejected. This approach is called a Saga Pattern, and you can find more information about it under this link.

Message operations

There are several features which are helpful for operationalizing your messages.

De-duplication

The name of this feature can be a little confusing. Personally, when I read “duplicate detection”, I expect that a message will be scanned and compared to other messages, but this is not the case here. The purpose of this feature is only to scan the MessageID field and look for the result in a defined period.

ForwardTo/SendVia

This feature can be described as Auto Forward. With it you can move your message to another queue or subscription of the same namespace. What this means is that when a queue or topic receives a message, it will remove it from that flow, and send it to another one.

Microsoft recommended creating topics which include one subscription forwarding a message to another topic, in order to improve throughput. Auto Forward has one issue, however: it does not support sending a dead-letter to another queue or topic.

Schedule messages

This is a straightforward feature. It is used to delay the queue by sending a message tagged with a specified time to be processed. This allows for synchronizing the messages with a time-based scheduler.

Scheduled messages do not appear in a queue or topic before the set time. Until then, you can cancel them, in which case the service bus will automatically remove them.

Azure Service Bus does not support recurring schedules for messages.

Prefetch

The purpose of this function is to optimize receiving messages from the service bus. With this functionality enabled, the listener can retrieve many more records than it needs to process at the moment. The big advantage of this feature is a more efficient throughput.

On the other hand, if your solution uses the ReceiveAndDelete mode, all prefetched messages acquired into the prefetch buffer are no longer available in the queue or topic. If you use the PeekLock mode, the messages will be locked and have a timeout until being available for processing.

So why is Prefetch not immediately available as an out-of-the-box feature? The answer is straightforward: because you need to make an informed decision on whether to switch it on.

The developer or architect needs to consider the pros and cons and evaluate whether or not they wish to use this feature. The reason for that is the risk of losing a number of messages or generating many errors in the processing flow.

Partitioning and session

What is a session in Azure Service Bus?

(Source)

With this feature we can implement FIFO queue in queue or subscriptions. This way, we can be sure that processing of our messages will happen in the right order.

Additionally, we can record the state of each messaging session and retrieve it at the next processing run:

This means that a session does not only allow ordering but also conveys information between the message runs.

Diagram of the sessions functionality

A single message broker handles a standard queue or topic and stores it in one messaging store.

What is partitioning?

Enabling the partitioning function separates the messages into many storages using a partition key which is unique to specific messaging.

All messages with the same partition key will be kept together. The partitioned queues and topics retain all of the advanced Service Bus features, such as support for transactions and sessions.

How does it work?

Partitioning segregates messages by partition key and puts them into storage. There we can keep them all in one place and select or find specific messages by their key. The partition key does not guarantee message ordering, so if you want to keep order, you need to use a session.

Diagram of the partitioning functionality

Differences between Standard and Premium Tier

Now we have an idea of the features, we can get back to pricing. Figure 4 presents features available in Premium and Standard pricing tiers. As mentioned earlier, at first look they are similar, but the difference is colossal.

The Premium option is faster and has higher throughput. All messages are separated at the CPU and memory levels which means that messaging works in a completely isolated run-time environment. This isolation, or a Message Unit, allows for predictable and repeatable performance.

Differences between pricing tiers

Further, in the Premium tier, partitioning is permanently enabled and cannot be turned off. However, it does not use SQL as a data store and consequently no longer has the possible resource competition associated with a shared platform. Additionally, in the Premium option, each entity can have two partitions, and maximum size of storage is 80 GB.

Therefore, if our solution needs to have high throughput, we are expecting a lot of large (max. 1MB) messages, and we want to be sure that every message is delivered, Premium is the way to go!

Summary

Azure Service Bus has a lot of extra features which can enhance our solution and improve throughput, sending and delivery.

The standard tier gives us a lot of options, but if we expect high message volumes or want to have predictable and repeatable performance, we should choose the premium option. We can use the base tier if we are still learning about Azure Service Bus, or we only want to use the queue feature.

I hope that this article sheds some light on the functionalities of the Azure Service Bus and what options are available to you. If you have any questions or would like to know more, just contact us!

[1] Jim Gray, Andreas Reuter, Transaction Processing — Concepts and Techniques, 1993, Morgan Kaufmann, ISBN 1-55860-190-2