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:
Source: Microsoft
Producers:
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.
Partitions:
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.
Source: Microsoft
See below code snippet to send message with partition key, you can use PartitionKey property of CreateBatchOptions. Replace
// 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:
Queues:
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.
Source: Microsoft
Topics:
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.
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
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. |