Grid/Hub vs Service Bus

This blog is to compare 3 Async messaging systems in Azure as there are lot of overlapping features among these 3

Queueing patterns

Let's first see what is the difference in terms of

• push/pull model
• queue/topics
• non partitioned/partitioned topics

The below list shows the services in various cloud providers such as AWS, GCP and Azure

Specific patterns on Azure are shown below

• Its worth noting that Event Grid is push based while other 2 are pull based
• Event Hub is for high thoughput scenario as it uses multiple partitions. Event Hubs also has the unique ability to ingest massive volume of data (1 million messages per second) in an unmatchable speed.
• Service Bus connects any devices, application or services running in the cloud to any other applications or services and transfers data between them. The data being transferred can be in XML, JSON, or text format.
• Azure Event Hubs focuses more on event streaming whereas Azure Service Bus is more focused on high-value enterprise messaging, which means the later is focused on messages rather than events.

When to use what?

• If you are implementing a pattern which uses a Request/Reply message, then use Azure Service Bus.
• Azure Event Hubs is more likely to be used if you’re implementing patterns with Event Messages. If you want a reliable event ingestor which can deal massive scale of event messages, then preferably you should go for Event Hubs.
• Use Event Grid is generally used for building reactive architecture.

Event Grids VS Event Hubs

• Event Grids doesn’t guarantee the order of the events, but Event Hubs use partitions which are ordered sequences, so it can maintain the order of the events in the same partition.
• Event Hubs are accepting only endpoints for the ingestion of data and they don’t provide a mechanism for sending data back to publishers. On the other hand, Event Grids sends HTTP requests to notify events that happen in publishers.
• Event Grid can trigger an Azure Function. In the case of Event Hubs, the Azure Function needs to pull and process an event.
• Event Grids is a distribution system, not a queueing mechanism. If an event is pushed in, it gets pushed out immediately and if it doesn’t get handled, it’s gone forever. Unless we send the undelivered events to a storage account. This process is known as dead-lettering.
• In Event Hubs the data can be kept for up to seven days and then replayed. This gives us the ability to resume from a certain point or to restart from an older point in time and reprocess events when we need it.

Event Hubs vs Service Bus

To the external publisher or the receiver Service Bus and Event Hubs can look very similar and this is what makes it difficult to understand the differences between the two and when to use what.

• Event Hubs focuses on event streaming where Service Bus is more of a traditional messaging broker.
• Service Bus is used as the backbone to connects applications running in the cloud to other applications or services and transfers data between them whereas Event Hubs is more concerned about receiving massive volume of data with high throughout and low latency.
• Event Hubs decouples multiple event-producers from event-receivers whereas Service Bus aims to decouple applications.
• Service Bus messaging supports a message property ‘Time to Live’ whereas Event Hubs has a default retention period of 7 days.
• Service Bus has the concept of message session. It allows relating messages based on their session-id property whereas Event Hubs does not.
• Service Bus the messages are pulled out by the receiver & cannot be processed again whereas Event Hubs message can be ingested by multiple receivers.
• Service Bus uses the terminology of queues and topics whereas Event Hubs partitions terminology is used.

Patterns

Event Grid

Event-hub

Service bus

---

Was this page helpful?

Yes No