Azure Service Bus vs Azure Event Hub: A technical guide

Azure Event Hub vs. Azure Service Bus: A comprehensive comparison

Azure Event Hub vs. Azure Service Bus: A comprehensive comparison
Author : Romil Kansara   Posted :

When we talk about messaging and event-driven architectures in the Azure ecosystem, two popular services stand out: Azure Event Hub and Azure Service Bus. While both services offer reliable messaging capabilities, they have distinct features and use cases. In this blog post, we’ll explore the core differences between Azure Event Hub and Azure Service Bus and delve into their key components and usage scenarios.

What is Azure Event Hub?

Azure Event Hub is a fully managed event streaming platform that enables the collection, storage and analysis of massive amounts of data. This data can be generated by applications, devices and IoT endpoints. It is designed for high-throughput scenarios, making it ideal for real-time event processing and big data streaming.

Event Hub follows a “pub/sub” model, where events are published to the hub and multiple consumers can process the events concurrently. With its partitioning and consumer group capabilities, Event Hub provides scalability and load balancing.

Here, are the key components of Event Hub:

Azure event hub

Source: Microsoft

The maximum size of a single event or a batch of events is 1 MB. Events larger than this threshold will be rejected.

Consumer group:
Consumer groups enable multiple applications or services to independently consume events from a single Event Hub. Each consumer group maintains its own offset, allowing different applications to progress at their own pace.

Event Hub divides the event stream into multiple partitions. Each partition is an ordered sequence of events. Multiple consumer instances can read from different partitions in parallel, providing high scalability and throughput.

Publishers should not be concerned with the specific partitioning model used by an event hub. Instead, they should only specify a partition key that will consistently assign related events to the same partition.

Azure event hub

Source: Microsoft

See below code snippet to send message with partition key, you can use PartitionKey property of CreateBatchOptions. Replace with your value.

// Create a batch of events 
using EventDataBatch eventBatch = await producerClient.CreateBatchAsync(options:new CreateBatchOptions(){
                PartitionKey = "<partitionKey>”

Checkpoints in storage:
Event Hub supports checkpoints to enable fault tolerance and resumable event processing. Checkpoints store the current offset or position of a consumer in a partition. This allows partition to resume from where it left off after a restart or failure.

What is Azure Service Bus?

Azure Service Bus is a versatile messaging service that facilitates communication between decoupled applications and components. It supports two primary messaging models: the “queue” model, where messages are sent to a specific queue and processed by a single consumer, and the “topic/subscription” model. This allows multiple subscribers to receive and process messages. Service Bus provides reliable message delivery, making it an excellent choice for enterprise messaging scenarios and application integration.

Service Bus contains below key components:

Service Bus Queues provide reliable one-to-one messaging with first-in-first-out (FIFO) delivery semantics. They ensure that messages are processed in the order they are received and guarantee message persistence.

Azure event hub message

Source: Microsoft

Service Bus Topics enable publish/subscribe messaging patterns, where messages are sent to a topic and then delivered to multiple subscriptions. Subscribers can filter messages based on specific criteria, allowing for efficient message distribution.

Azure service bus queue

Configuration for parallelism and throttling:
Service Bus provides configurable settings for controlling parallel message processing and preventing throttling, such as the MaxConcurrentCalls parameter and PrefetchCount. These settings ensure optimal performance and prevent overloading of consuming applications.

Session-enabled entity:
Session-enabled entities provides guaranteed FIFO for queue and topics. A sender can create session while sending message by setting up the SessionID property. When the session is accepted and held by a receiver client, the client holds an exclusive lock on all messages with that session’s SessionID in the queue or subscription. It will act like sub queue as denoted in the following diagram.

Set SessionID property to ServiceBusMessage

Azure service bus message

Source: Microsoft

The orange blocks have the SessionID = 1 so, sub queue will be created for orange blocks and it ensures it will receive by first receiver, this way it ensures ordering for orange blocks. Same way it works for green and blue. However, for purple block the diagram shows there is no active client which means that no messages delivered from this SessionID.

For example: A decoupled employee management application where employee and company are separate services. Company service needs to send message to update employee’s detail which can be handled by employee service.

Imagine a scenario where a user updates a position multiple times in quick succession, or where multiple users update the details of the same employee in a very short period. In these cases, you don’t want to overwrite changes, and you want to process the updates in the same order as they were received. To achieve this, you can enable sessions and use the employee ID as the SessionID. This will ensure that messages for the same employee are always processed sequentially.

Key differences between Azure Event Hub and Service Bus

Aspect Azure Event Hub Azure Service Bus
Purpose and use cases Real-time event processing and big data streaming. Decoupling applications, message queuing and publish-subscribe messaging.
Messaging model Publisher/Subscriber (Pub/Sub) model. Queue model and Topic/Subscription model.
Throughput and scalability Optimized for high-throughput scenarios. Moderate throughput suitable for moderate messaging demands.
Message retention Limited retention period (typically 1 to 7 days). For premium plan it is 90 days. Longer retention periods (up to 7 days or more up to 14 days).
Protocols Supported Supports HTTP and AMQP 1.0 protocols. Supports HTTP, AMQP 1.0 and HTTPS protocols.
Partitioning and consumer groups Employs partitioning for scalability and uses consumer groups. Utilizes partitioning for scalability and offers consumer groups.

This table provides a concise overview of the key differences between Azure Event Hub and Azure Service Bus, highlighting their distinctive features and functionalities. Understanding these differences will help you make an informed decision when choosing the appropriate messaging service for your specific business requirements.

Business case for Azure Event Hub

Imagine you run an online retail business and you want to understand your customers better to improve their shopping experience. By leveraging Azure Event Hub, you can collect and analyze real-time customer behavior data, such as clicks, searches and purchases. With the help of Event Hub’s high-throughput capabilities, you can process this data efficiently and gain valuable insights.

Here’s a coding snippet showcasing how to send customer behavior events to an Azure Event Hub:

//C# code to Event Hub message producer
//TODO: Replace the " <EVENT_HUB_NAMESPACE>" and "<HUB_NAME>" placeholders.
EventHubProducerClient producerClient = new EventHubProducerClient(
    new DefaultAzureCredential());

// Create a batch of events 
using EventDataBatch eventBatch = await producerClient.CreateBatchAsync();

if (!eventBatch.TryAdd(new EventData('{"customerId": "12345", "action": "click", "product": "Smartphone"}')))
        // if it is too large for the batch
        throw new Exception("Event data is too large for the batch and cannot be sent.");
// Use the producer client to send the batch of events to the event hub
await producerClient.SendAsync(eventBatch);
Console.WriteLine($"A event data has been published.");

Business case for Azure Service Bus

For financial institutions, detecting fraudulent transactions is critical to safeguarding their customers and their reputation. Azure Service Bus can play a vital role in this scenario by enabling real-time communication between various fraud detection components. By utilizing Service Bus queues, you can process and prioritize incoming transaction data for analysis and investigation.

Here’s a coding snippet demonstrating how to process transactions using Azure Service Bus

// C# code to process transactions using Azure Service Bus
using System;
using Microsoft.Azure.ServiceBus;

public class FraudDetectionProcessor
    static IQueueClient queueClient;

    public static void Main()
        string serviceBusConnectionString = "<your_connection_string>";
        string queueName = "<your_queue_name>";

        queueClient = new QueueClient(serviceBusConnectionString, queueName);



    static void RegisterOnMessageHandlerAndReceiveMessages()
        var messageHandlerOptions = new MessageHandlerOptions(ExceptionReceivedHandler)
            MaxConcurrentCalls = 1,
            AutoComplete = false

        queueClient.RegisterMessageHandler(ProcessMessageAsync, messageHandlerOptions);

    static async Task ProcessMessageAsync(Message message, CancellationToken token)
        // Process the transaction data for fraud detection
        // ...

        await queueClient.CompleteAsync(message.SystemProperties.LockToken);

    static Task ExceptionReceivedHandler(ExceptionReceivedEventArgs exceptionReceivedEventArgs)
        Console.WriteLine($"Message handler encountered an exception {exceptionReceivedEventArgs.Exception}.");
        var context = exceptionReceivedEventArgs.ExceptionReceivedContext;
        Console.WriteLine("Exception context for troubleshooting:");
        Console.WriteLine($"- Endpoint: {context.Endpoint}");
        Console.WriteLine($"- Entity Path: {context.EntityPath}");
        Console.WriteLine($"- Executing Action: {context.Action}");
        return Task.CompletedTask;

Azure Event Hub vs. Azure Service Bus – what to choose?

Let’s say if you want to prepare no-SQL data from SQL relational data (load Cosmos DB based on MS-SQL data), you can use Event Hub to send messages of all SQL row. The receiver can process messages to dump into Cosmos DB.

However, if you want to use messaging services to decouple the application as explained above, Azure Service Bus is a good option. By understanding their key components and usage scenarios, you can make informed decisions.

Remember, choosing between Azure Event Hub and Azure Service Bus depends on factors such as data volume, throughput needs, messaging patterns and ordering requirements. So, evaluate your use case carefully to make the right choice and leverage the full potential of Azure’s messaging services.

How can Softweb Solutions help with Azure Event Hub and Azure Service Bus?

Softweb Solutions is a Microsoft Gold Partner with extensive experience in Azure Event Hubs and Azure Service Bus. We can help you with the following:

Design and implementation

Here are some examples of how Softweb Solutions can help with Azure Event Hubs and Azure Service Bus:

  • Our certified Microsoft developers can help you build a real-time streaming pipeline that ingests data from multiple sources and delivers it to downstream systems.
  • Our team of experts can help you implement a publish/subscribe messaging pattern that allows applications to communicate with each other without knowing about each other.
  • We can implement a request/reply messaging pattern that allows applications to request a response from another application.

If you are looking for help with Azure Event Hubs or Azure Service Bus, Softweb Solutions has all the experience and expertise to help you. Contact us today to learn more about our services.

Need Help?
We are here for you

Step into a new land of opportunities and unearth the benefits of digital transformation.