Compare Azure Messaging Services | How to Chose | Azure Service Bus vs Event Hub vs Event Grid

In our fast-paced, digital world, different components of a software program need to communicate with each other seamlessly, securely, and efficiently. Consider an online shopping site for instance; you have a user interface for product selection, a payment system handling transactions, and a delivery system managing shipments. These systems need to ‘talk’ to each other, and this is precisely where Microsoft Azure Messaging Services steps in.

The goal of Azure Messaging Services, or any messaging service for that matter, is to decouple applications to facilitate horizontal scaling. For communication, a messaging technique is employed where one application sends the message, and another receives and responds to it.

Azure Messaging Services in Simple Terms

Think of Azure Messaging Services as a kind of digital post office. It helps to send the message from one entity to another. Post office deals with many kinds of messages - for ex, letters, packages, and parcels. And they are in different shapes and sizes. They use different transport mechanisms to deliver these messages.Based on the message type, size, priority, and how many they chose the transport mechanism that suits them best. Some are small and need to reach super quickly, some are huge but there’s no hurry for them, while there could be a whole bunch of messages to just one entity. So, they have to use either Van, Train, or flight based on requirements.

The choice of transport mechanism, or in this case, the choice of Azure Messaging Service — be it Service Bus, Event Grid, or Event Hub, depends on factors such as the type, size, quantity, and urgency of the messages, and the frequency of their receipt.

To select the right messaging service, we need to understand the characteristics of the message:

1. what is the message?
2. Message size?
3. How many messages?
4. Who is receiving them, and how frequently they are being sent?

Based on these factors, you can determine the most suitable solution.

Decoding Messages: Commands and Facts

In Microsoft’s messaging universe, messages are categorized into two types:

1. Commands
2. Facts

Commands - Azure Service Bus

A command is a directed instruction for a service to execute a task. Azure Service Bus handles these types of messages, where a command is issued via a message and placed in a queue or topic for the receiver to pick up and process.

Use-case:

Consider the order processing in an e-commerce application. When a customer places an order, they are essentially sending a command to the system, like “Place Order”. This command triggers the order processing workflow in the system. Here, we have two decoupled software components, one dealing with issuing a command to place the order, and the other handling the order processing workflow.

Facts

Facts are simply factual messages conveying information. They can be further divided into two types:

1. Time Series Facts
2. Discrete Facts

Time Series Facts - Azure Event Hub

Time Series Facts refer to telemetry data relying on time series. An example of this is sensor data, where a sensor sends temperature data every second. Azure Event Hub is used to manage this voluminous, time-stamped data.

Use-case:

Consider sensors placed in different areas of a forest to detect and track forest fires. These sensors capture real-time data such as temperature, smoke levels, humidity, wind direction, and wind speed every minute. This is a massive amount of data. Azure Event Hub can process this incoming stream of data in real time, raising alerts during a serious fire or generating business intelligence reports offline.

Discrete Facts - Azure Event Grid

Discrete Facts are event-like, point-in-time facts. An example is when a new user signs up for your service or logs in from a different location, triggering security protocols to ensure legitimacy. This is where Azure Event Grid comes into play.

Use-case:

Take the order processing scenario in an e-commerce application again. After an order is placed via Azure Service Bus and processed, a series of activities like updating stock, scheduling delivery, and issuing an invoice needs to happen. Each of these processes can be triggered as an event using Azure Event Grid.

Understanding Differences to Make the Right Choice

Choosing between Azure Service Bus, Event Grid, or Event Hub can be tricky. While you can use Azure Service Bus topics for publish/subscribe scenarios, where a message can be consumed by multiple subscribers, there are key differences between Azure Service Bus and Azure Event Grid that might make one more suitable than the other, depending on the use case

Here are some points of differentiation to help you choose the right service:

1. Event Schema: Event Grid uses a specific event schema, which makes handling events from different sources easier.
2. Fan-out capabilities: Event Grid is designed for high-volume, low-latency scenarios and can distribute the same message to many listeners.
3. Delivery Guarantees: Service Bus and Event Grid have strong delivery guarantees, but their strategies differ. Event Grid will keep retrying to deliver the event for up to 24 hours.
4. Push vs. Pull Model: Azure Service Bus uses a pull-based model where the receiver actively checks for new messages, while Event Grid uses a push-based model where events are sent to the event handlers as they occur.
5. Filters: Event Grid allows you to filter events on the server side, meaning only events of interest are sent to your service. With Service Bus, all messages are delivered to the subscribers, and filtering has to be done client-side.

Conclusion

To determine the right messaging service, define your message first. Understand the sender and receiver, the message size, quantity, frequency, and urgency of processing. Then, assess the capabilities of each messaging service and map them against your needs. This exercise will enable you to choose the right service for your workload.

Azure Messaging Services indeed acts as a digital post office, managing the delivery of your messages effectively. Stay tuned for more insights on each of these individual components in the coming articles. Until then, happy exploring!