When to use Event Grid and when to use Service Bus

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.

Message

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.

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 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).	Yes (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.
Serverless	Yes Pay only for the amount you use Event Grid (operations charges).	No Base charges + operations charges.
Polling mechanism	Push	Pull (.NET, Java, JavaScript, and Go SDKs provide push-style API)
Message payload encryption	No	Yes
In-Order Delivery (FIFO)	No	Yes
Duplicate Detection	No	Yes
Transactions Support	No	Yes
Messages/Events to multiple subscribers	Yes	Yes
Retry mechanism	Yes	Yes
Dead lettering	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.
Batch Processing	Yes	Yes
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

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 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