When I started looking into solutions for routing events to our new microservice, it took me a while to get a clear picture of the differences between Azure Event Grid and Azure Service Bus. In this blogpost I want to share my findings and try to show what the differences are. Hopefully this will help you find the best solution for your problem, because these are not a one or the other products. Both Event Grid and Service Bus have different characteristics, and both can be a valid solution for your problem.
Azure Event Grid
- Event Grid is more like a router for events
- Push based model, based on HTTP calls (both ingoing and outgoing)
- Event Grid has an available endpoint where you can send events (http post). When receiving events, EventGrid will route them to subscribers, based on the configuration made in Event Grid (This can be done through the portal or with a management API)
- With pay on use solutions (with for example Azure functions) you don’t pay anything when there is no traffic. Not for Event Grid or for your receiving and sending application, because there are no polling threads that need to be active)
- Retry mechanism
- Retries at 10, 30 seconds, 1, 5, 10, 30 minutes, 1 hour, every hour up till 24 hours, with small randomization of those times
- Retries at 10, 30 seconds, 1, 5, 10, 30 minutes, 1 hour, every hour up till 24 hours, with small randomization of those times
- Filtering
- Can be done by EventType and Subject (custom string per event)
- For Subject only filtering on StartsWith and EndsWith are available (nothing more complex)
- Not transactional (because of retries you have a reasonable guarantee of at least once delivery)
- Doesn’t have a local emulator, so local testing is tricky
Azure Service Bus
- Service Bus is a queue-based system
- Pull based, receiving needs to pull a queue (ingoing is writing to queue, outgoing is pull from queue)
- The application writes an event to a queue, the receiving system monitors this queue. With Azure Functions/WebJob polling the queue is fully abstracted, but there will always be an active thread
- Retry mechanism
- Can be customized by reader, but both writing, and reading could be done 100% transactional
- Azure functions/webjob triggers offer an out of the box solution for this
- Filering
- Much more customization possibilities compared to Event Grid. SQL style language to write filters for topics
- Much more customization possibilities compared to Event Grid. SQL style language to write filters for topics
- 100% transactional (in and out)
- Service Bus also doesn’t have a good local emulator, but I could imagine using an azure queue as an alternative should be possible. I didn’t test this or do much research on this though
For my project Event Grid was the system we were looking for. We are building a notification system, where 100% accurate delivery is not required. The cost savings and ease of development were the deciding factors for us to go with Event Grid. We almost switched to Service Bus when we figured out that there was no local emulator, because this is quite limiting during development, but because Service Bus has the same problem, we went with Event Bus anyway.
I hope this comparison will help you pick the correct eventing solution for you.