The document compares Azure Event Grid and Azure Service Bus messaging platforms. Event Grid uses a publish-subscribe model and push-based messaging, while Service Bus uses a push-pull model. Event Grid messages are immediately deleted after delivery, risking loss if not handled properly by subscribers. Service Bus retains messages even if not acknowledged, preventing loss. Additionally, Service Bus allows ordered delivery, transaction support, and viewing tools not available for Event Grid. The document recommends Service Bus over Event Grid for microservices requiring reliable messaging between components.

1. Azure Event Grid
Vs.
Azure Service Hub
Sandun Perera
Software Architect @ Geveo Australasia
2024/01/31

2. The context
• Azure messaging platforms
• Commonly used in microservices designs
and as an inter-system communication
backbone.
• Need to evaluate based on system
requirements to decide which one to use.

3. What is your messaging
platform?
• Azure Event Grid
• Azure Service Bus
• Azure Notification Hub
• WSO2 Enterprise Service
Bus
• Apache Kafka
• Other?

4. Azure Event Grid
• Uses publish-subscribe model.
• Enables event-based message passing.
• Comfortable with reactive programming.
• Publisher emits messages and forget.
• Subscriber will decide which events to handle.
• Deeply integrated with Azure services for easy integration
with third-party services.
• Event consumption is simplified by avoiding polling.
• Effective and efficient event routing.
• Event Grid is a global resource, hence no regional barriers.
• Can push messages to larger number of subscribers by
design.

5. Azure Service Bus
• Works as push-pull model.
• More targeted for transactional messaging.
• Service bus is a regional resource and limited to the
region.
• Limited number of connections for polling.

6. Push Vs. Pull
Event Grid uses a Push mechanism to proactively send events to Subscribers, while Service Bus
employs a Pull mechanism where subscribers retrieve messages. The risk of overwhelming
Subscribers with Event Grid's push approach can lead to throttling or unresponsiveness. To
address this, a test was conducted by a team, with a Logic App as a Subscriber, revealing failures
in processing due to the rapid delivery of 200 messages in 50 seconds. Introducing a Service Bus
between Event Grid and the Logic App, allowing the Logic App to work at its own pace, proved
essential for resolving the issue.
In contrast, Service Bus's Pull mechanism allows Subscribers to fetch messages at their desired
rate, preventing exceptions even with a high volume of events. The revised architecture included a
Service Bus between Event Grid and its Subscriber, with the Logic App broken into individual
functions for better control. Testing with JMeter demonstrated successful processing of 200
messages in 7-8 minutes and scaling up to 1000 messages in 13-14 minutes, highlighting the
enhanced resilience and fault tolerance achieved by integrating Service Bus.

7. Loss of messages
Service Bus requires explicit deletion of messages from the subscription queue under peek and
lock mode, ensuring that Subscribers control when messages are removed. In contrast, Event Grid
immediately deletes messages from the Event Grid Topic upon delivery to the Subscriber. In above
experiments, the team observed that in Event Grid, if exceptions occurred during event processing
and were not appropriately handled by the Subscriber, such as forwarding the message to a dead
letter queue, the messages could be lost.
Conversely, in the case of Service Bus, when exceptions occur during message processing, the
message is automatically moved to the Dead Letter queue, allowing for automatic retries. Unlike
Event Grid, Service Bus Subscribers do not need to explicitly send messages to the dead letter
queue; the system automatically routes messages to the Dead-Letter queue in the event of
exceptions.

8. Order of delivery
Event Grid does not provide a guarantee regarding the order of event delivery,
while in the case of Service Bus, the utilization of Message sessions allows us to
obtain ordered messages.

9. Duplicate detection
Event Grid lacks support for transaction and duplicate detection, while it is a
feature that is available in Service Bus.

10. Viewer
While the application is in production or development, it is crucial to monitor the messages
published in the Azure Messaging Service. Microsoft has not introduced any default product for
viewing Event Grid messages. However, external applications like EventGridViewer can be
integrated as subscribers to the events. It's important to note that EventGridViewer doesn't store
events, so if retrospective event analysis is needed, another subscriber must be added to store the
data in a datastore. Additionally, a mechanism for filtering and viewing stored events should be
implemented. It's worth mentioning that this subscriber may face throttling if messages are posted
to it at a higher rate.
In contrast, Microsoft has released a tool named Service Bus Explorer, specifically designed for
inspecting published messages. For details, please refer to the version of Service Bus Explorer
available in the Azure Portal.

11. Message retention and lost policy
• Both EventGrid and ServiceBus are resilient in trying to deliver the message to their Subscribers.
• The EventGrid will drop the event if either of the limits of the retry policy is reached.
Maximum number of attempts - Between 1 and 30. The default value is 30.
Event time-to-live (TTL) - The value must be between 1 and 1440. The default value is 1440
mins.
• EventGrid drops the event to the Dead-letter queue if configured, otherwise, the event is permanently
lost. Also, if the dead letter container is not online for 4 hours, then the event will be lost.
• In the case of Azure Service Bus, the messages are pushed to the subscriber queues. While creating a
Subscriber one can configure how long the message will remain in the Subscription queue before
being removed. One can even set a setting that may even allow a message to remain in the
subscription queue for a very long time.

12. Dead letter queue
• Both Service Bus and Event Grid support the Dead-letter queues. The only difference is that in Service
Bus Dead-letter queue is available by default whereas in Event Grid it needs to be configured using a
Storage account.

13. Integration with azure resources
Many azure
resources have
default integration
with Event Grid.

14. When to use what
In the context of Microservice architecture, where microservices exchange valuable messages,
opting for Service Bus over Event Grid is advisable for the following reasons:
1. Service Bus permits subscribers to consume messages at their own pace, unlike Event Grid, which
pushes events to subscribers, leading to potential exceptions when the event push rate exceeds the
Subscriber's processing speed. This feature of Service Bus reduces errors in the system, enhancing
resilience and ease of maintenance.
2. Service Bus enables messages to be read in Peek and Lock mode, safeguarding them from being lost in
case of exceptions. Conversely, with Event Grid, there is a risk of events being lost.
3. Service Bus allows messages to be read in an organized manner, while Event Grid delivers messages in
an arbitrary order.
4. Service Bus supports Transaction and Duplication detection, a feature not available in Event Grid.
5. Service Bus offers superior tools like Service Bus Explorer for monitoring and maintenance, whereas
Event Grid lacks comparable out-of-the-box tools. This makes it more convenient to observe, manage,
and troubleshoot potential issues with Service Bus in the future.

15. Formal reviews
• Event Grid is easy to use and administer.
• Service Bus is easier to deal with business in overall.
• Reviewers think Event Grid meets the needs of business better than Service
Bus.

16. Reference
• https://www.linkedin.com/pulse/azure-event-grid-vs-service-bus-eklavya-gupta/

17. QUESTIONS?

18. THANK YOU!