Asynchronous messaging and Event driven architectures are the building blocks of a truly scalable system, where the services can talk to each other and can scale up and down independently. Where, the outage of one service do not impact the working of others.
However, whenever any team starts to define these architectures on Azure, there is always an argument on when to use Event Grid and when to use Service Bus. By and large both of the service offering provides very similar technical capabilities and quite often can replace one another. In this article, I have tried to cover when we should use Event Grid and when to use Service Bus.
Before starting with the Event Grid and Service Bus lets first try to understand what exactly the difference between an event and a message is, which often is an area of confusion.
A message is the raw data or payload that is been generate 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.
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 has triggered the event. The publisher of the event has no expectation 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 lets discuss how the Service Bus is different form Event Grid, in the tabular format.
|Parameters||Event Grid||Service Bus|
|Purpose||React to status changes, Event-based architecture (for example: sending an event on file uploaded in Azure Blob storage, event on a job completion)||Reliable Message processing (for example: financial transactions, ecommerce order processing etc.)|
|Throughput||Event Grid provided more throughput 5000 events /sec or 1 MB /sec (whichever is met first) per topic||Microsoft has not provided any guaranteed throughput for Service bus (older documentation used to claim it to be 2000 messages /sec)|
|At-Least-Once delivery guarantee||Yes |
(based on retries. Drop or dead lettering after maximum retires).
(using PeekLock receive mode. It’s the default)
|At-Most-Once delivery guarantee||No||Yes |
(using ReceiveAndDelete receive mode)
|Connection state recovery In case of disconnect can client resumes from the same state?||No||Yes|
|Communication Protocols||HTTP||AMQP, TCP/IP, HTTP|
|Maximum number of topics||Event Grid supports 100,000 topics in an event domain.||Service Bus supports 10,000 topics per namespace for the Basic or Standard tier. For the Premium tier, 1,000 per messaging unit (MU). Maximum limit is 4,000.|
|Maximum number of subscribers||500 subscriptions per topic||2,000 subscriptions per topic|
|Intended Consumers / Expects action?||No||Yes|
|Data/Message Content||Event Grid is used for light weight messaging (called events) with no data that has triggered the event.||Service Bus is used to deliver reliable messages, asynchronously, which are intended to serve a purpose.|
Pay only for the amount you use Event Grid (operations charges).
Base charges + operations charges.
|Polling mechanism||Push||Pull |
|Message payload encryption||No||Yes|
|In-Order Delivery (FIFO)||No||Yes|
|Messages/Events to multiple subscribers||Yes||Yes|
|Multi-region data replication (storage)||No||No|
|Receive mode||Push||Peek & Lock|
Receive & Delete
|Lock duration||No Locks||30 seconds (default)|
You can renew the message lock for the same lock duration each time manually or use the automatic lock renewal feature where the client manages lock renewal for you.
|Message Lifetime||No retention. Event Grid expires all events that aren’t delivered within maximum number of delivery attempts (default is 30) and the event time-to-live (default is 1440 minutes).||>7 days|
|Message Size||The size of an array can be up to 1 Mb. Each event in an array is limited to 64 KB.||256 KB for Standard tier, 1 MB for Premium tier.|
|Message routing and filtering capabilities||Yes||Yes|
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 a full control on 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 message.
Event Grid Vs Service Bus
Service Bus VS Event Grid
Reblogged this on Nishant Rana's Weblog.