For many architecture designs, I need to make the choice between Azure Service Bus and Event Grid. Azure Service Bus is more targeted to transactional messaging, Event Grid is optimized for handling discrete events. Both services are publish/subscribe engines. There is one big difference: Service Bus works with a push-pull model, whilst Event Grid uses a push-push model. When in doubt, I always tend to go for Service Bus, the Swiss Army Knife of Azure Messaging. Here, I would like to share my reasoning with you!
Why I often prefer Service Bus
You control the processing speed
In Azure Service Bus, the receiving app can choose the speed at which it processes messages or events. Even when the sender is sending a huge load of messages, the receiver is not impacted by that (load leveling). In Event Grid, the sender dictates the rate at which messages have to be processed, because Event Grid immediately pushes them forward. Some SaaS applications might have throttling enabled, which may lead to a cascading effect of exceptions. Legacy applications are often not able to cope with a high number of messages to be processed at the same time.
More firewall friendly
Thanks to the push-pull model of Azure Service bus topics, the solution is much more fire-wall friendly. In case the receiving application is behind a corporate firewall, there are no issues to enable the messaging, because it gets initiated by an outbound connection. With Azure Event Grid, the receiving application must have an HTTP endpoint exposed, which requires an explicit firewall configuration and additional security measures.
Better reliability
The peek-lock pattern of Azure Service Bus provides at-least-once reliability. The receiving app controls when messages get processed (e.g. not during maintenance windows) and when they can be deleted from the queue. If things go wrong, messages end up in the deadletter queue: ready to be investigated. Event Grid achieves more or less the same reliability, but through the retry pattern. This try-and-error approach does not seem the best option, as over time, the receive app may become overloaded by retried events.
More control and visibility
Whilst the monitoring experience of Event Grid gets continuously improved, I’m convinced that Service Bus offers a much better experience during issues and troubleshooting. With Service Bus, you can easily stop the receiving app, without losing messages. This allows you to start troubleshooting is a controlled fashion. Thanks to the Service Bus Explorer, you can clearly see the number of messages within the queues and subscriptions and you are even able to inspect their content.
Ordered delivery
Sooner than later, you might run into business requirements that demand (partial) ordered delivery. Thanks to Service Bus sessions, you can enabled fine-grained FIFO (Fire In First Out).
We are using Event Grid, so we are doomed?
Absolutely not! First of all, your business requirements and non-functionals might not require all of the above. Secondly, you can always take benefit of using Service Bus as an Event Handler for Event Grid. If one of your receiving apps is experiencing throttling issues, you can subscribe to the events with a Service Bus queue and start pulling the messages from there!
Conclusion
With the current technology choices at our disposal, the answer is often “it depends”. So yes, I am still using Azure Event Grid within my Azure solutions, but when in doubt, I tend to go for Service Bus. Do you have another opinion on this matter? No problem at all. I am more than happy to learn from it!
Cheers
Toon
