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.

ParametersEvent GridService Bus
PurposeReact 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.)
ThroughputEvent Grid provided more throughput 5000 events /sec or 1 MB /sec (whichever is met first) per topicMicrosoft has not provided any guaranteed throughput for Service bus (older documentation used to claim it to be 2000 messages /sec)
At-Least-Once  delivery guaranteeYes
(based on retries. Drop or dead lettering after maximum retires).
Yes
(using PeekLock receive mode. It’s the default)
At-Most-Once delivery guaranteeNoYes
(using ReceiveAndDelete receive mode)
Connection state recovery In case of disconnect can client resumes from the same state?NoYes
Communication ProtocolsHTTPAMQP, TCP/IP, HTTP
Maximum number of topicsEvent 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 subscribers500 subscriptions per topic2,000 subscriptions per topic
Intended Consumers / Expects action?NoYes
Data/Message ContentEvent 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.
ServerlessYes
Pay only for the amount you use Event Grid (operations charges).
No
Base charges + operations charges.
Polling mechanismPushPull
(.NET, Java, JavaScript, and Go SDKs provide push-style API)
Message payload encryptionNoYes
In-Order Delivery (FIFO)NoYes
Duplicate DetectionNoYes
Transactions SupportNoYes
Messages/Events to multiple subscribersYesYes
Retry mechanismYesYes
Dead letteringYesYes
Multi-region data replication (storage)NoNo
Receive modePushPeek & Lock
Receive & Delete
Lock durationNo Locks30 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 ProcessingYesYes
Message LifetimeNo 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 SizeThe 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 capabilitiesYes Yes
Table 1.0: Comparison of Event Grid and Service Bus

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: