Azure Service Bus

Azure Service Bus is a secure, highly available & reliable Platform-as-a-service (PaaS) enterprise integration message broker for asynchronous transfer of data between applications. It supports Advanced Message Queuing Protocol (AMQP) which is a TCP-based efficient and reliable open protocol and makes a solution vendor-neutral. A developer can use different client libraries to connect to the message broker.

A sender sends messages to the queue. Queue sends back the ACK receipt after successfully replicating the message. On the other side, A receiver connect to the queue to retrieve a message and after completing the processing, it sends back an ACK for message deletion. A message can be moved into a Dead-letter queue (DLQ) to discard or later consumption, in case of an error.

Use Case for Service Bus

It is useful when an application wants to send a message to other applications and expect them to perform a specific action eg processing order or perform a series of workflow after a user is added to a resource group.

Azure Service Bus supports various advanced queuing operations and some of the key differentiating capabilities are:

Azure Event Grid

Azure Event Grid is a managed event routing service that routes events from Azure and non-Azure resources. It distributes the events to registered subscriber endpoints. Event Grid distributes events from different sources to different handlers, such as Azure Functions or logic apps.

Azure services have predefined topics to which messages could be published. These messages are available for subscription from the appropriate source. For custom topics, you simply create your Event Grid topic and then begin publishing and setting up subscriptions. The topic has an endpoint to publish messages and a set of keys for secure access.

The use case for Event Grid

Use an event grid when you want to implement the PUSH model i.e. you want to avoid long polling. Instead, events are routed immediately to an endpoint that you specify. In many cases, it can also lead to cost savings because it removes the overhead of polling on a regular basis and instead triggers code only when it is needed to consume an event. For example, you want to take action when a new user is added to the resource group or a file is uploaded to blob storage.

When to use Event Grid and when to use Service Bus

Message

A message is a raw data or payload that is been generated by the producer for the target consumers and persist until consumed or expired. The publisher expects the message to be consumed by the targeted consumer and likely wants some kind of response or action to occur. A contract exists between the producer and the consumer. For example, the publisher sends a message with some data and expects the consumer to generate some report from the data and send back a response when completed.

Event

An event is a lightweight message for the notification of a change in state. The event data has information only about what has happened and not the data that triggered the event. The publisher of the event has no expectations about the handling of the event. The consumer decides on what to do with the particular event. There can be ZERO or more subscribers that will receive each event. For example, an event may be generated when a file is created and have information about the file, but not the file content.

In simpler words, in a message-driven system publisher knows the intended consumers, whereas in an event-driven system the consumer decides what events it wants to subscribe to.

Now we understand events let's discuss how the Service Bus is different from the Event Grid, in the tabular format.

Conclusion

In short, both these services are used for delivering events and messages throughout a solution and have many similarities. However, each service is designed for certain scenarios and can be used based on necessity.

Use Azure Event Grid when you need dynamic scaling to process millions of events with high throughput, velocity, and near-real-time. The Event Handler is capable to handle the load and provide enough throttling to protect from failure.

Use Service Bus when you need to have full control of the pace of processing the messages, need advanced features like transactional support, sessions, FIFO, duplicate detection, etc., and require the consumer to make sure of a taking some action on the message.

Reference: