Choosing between Azure Service Bus and Azure Event Hub

Azure provides various messaging solutions such as Azure Storage Queues, Services Bus, Event Grid and Event Hub. Which one should you use and why? This post uses real business examples to illustrate the difference between Azure Service Bus and Azure Event Grid to assist in your architecture decision-making process.

Pull from Azure Service Bus

The previous post looked at the benefits of changing push to pull with a publisher-subscriber pattern using Azure Service Bus.

Figure 1 below, taken from the previous post, illustrates how an online booking tool (OBT) publishes booking messages to a topic where travel providers can subscribe and pull bookings from a queue.

Figure 1. Publisher-Subscriber pattern using an Azure Service Bus topic

But what happens if the travel provider doesn’t want to pull messages from a queue or has no capacity or appetite to develop a worker service? What if the only option is to call the travel provider’s REST API?

Push with Azure Event Grid

Let’s consider pushing the bookings to the travel provider’s REST API. Wait a minute! The previous post outlined various issues around availability, scalability, and reliability when pushing bookings to the travel provider’s API. That’s why the architecture was changed to a publish-subscribe pattern using an Azure Service Bus.

As shown in Figure 2 below, instead of pushing bookings from the OBT directly to multiple Travel Provider APIs resulting in high coupling and fragility, use Azure Event Grid to notify a serverless function when a booking is available to transform the event in an API call to a travel provider’s endpoint.

Figure 2. Event-driven architecture using Azure Event Grid

Let’s review the benefits of Azure Event Grid:

1. Availability – the OBT export remains operational even if one or all the travel provider APIs are temporarily unavailable
2. Reliability – when a travel provider’s API is temporarily unavailable, Event Grid will perform automatic retries for up to 24 hours until the API is available again
3. Scalability – each travel provider is responsible for scaling their own API. If failures are experienced, possibly due to load, Event Grid will delay deliveries and retries to accommodate for downtime
4. Observability – Azure provides dashboards to view event subscriptions and failed events
5. Extensibility - adding additional travel provider subscriptions doesn’t increase the load on the OBT. Developers only need to build the Azure Function to translate a booking event into a REST API call
6. Loose coupling – OBT developers publish events without knowing who, when or how the travel provider will consume the event
7. Responsiveness – the travel agent can place a booking fast without the need to wait around for bookings to be exported
8. Simplicity – fewer components are needed since we can eliminate the bespoke dashboard, scheduler, and read/writing export statuses to a database

Which is better, Azure Service Bus or Azure Event Hub?

It depends on the use case and business requirements.

Azure Service Bus works well when services can pull requests from a queue or if you need features such as guaranteed ordering, transactions, duplicate detection or long-running operations with renewable locks.

Azure Event Hub works well when requests are pushed to a service such as an API and events are processed within 24 hours and endpoints do not take longer than 30 seconds to respond.

Would you like to find out more or discuss your use case? Get in contact with our team today.

Would you be interested in learning more about messaging and queuing systems? Have a read of these other blog posts:

• Why messaging systems matter to SaaS
  
  
• 8 Benefits of switching from a push to a pull system