You are currently viewing Azure Solutions: Message Based vs Event Based

Azure Solutions: Message Based vs Event Based

There are many options in Azure services which can be used for integration solutions. Some of them are:

All of these services are used for sending some information from one place (application) to other application or applications. From superficial comparison it may appear that these services are competing with one another. It may appear that all of these services are offering same functionality to send / receive information.

But these services are not service same purpose !

Some of them deal with events and should be used with event based solution. Some of these services are best suited for event based communications while others are best for message based communications.

But now the question is how events are different from messages.

Events vs Messages

Event is lightweight notification of a condition or state change.

Message is the raw data that is created by service and that has to be consumed or stored elsewhere.

Publisher Perspective

When an event is published, publisher does not care about how it is handled. The consumer has option to ignore the event.

While in case of messages, publisher knows exactly who is going to receive it and how the message would be consumed.


In case of events, consumer can subscribe to events. Whenever event is raised, the consumer can start their code to handle that event in near real time automatically.

In order to read messages, consumer have to continuously poll to check if any message is received. The polling interval may vary based on system design.


In events, payload contain information about the data. While in case of messages, payload is the data.

Let’s take an example!

In this section, let’s try creating two logic apps – one based on events, while other based on messages concept.

This section assumes that you have access to Azure portal.

It also assumes that you have created instance of storage account and a queue with name “sample-storage-queue” and a container with name “demo-container“. This also assumes that Event Grid notifications are already setup in your subscription.

Event Based Logic App

In this logic app, use designer and add a trigger based on Event Grid. This trigger should take if the blob is created. If it is created then this logic app would send the email notification. The logic app designer view looks like below:

As you can see, there is no polling interval and the trigger is subscribing to the events.

Messaging Based Logic App

In this logic app, use the designer view and add the trigger is based on Blog Storage. This trigger looks as shown in below snapshot and it has polling interval.

Validating this setup

Download Azure storage explorer. Login to your Azure account in that.

Then go to your container and add new file. I uploaded file at 4:42 PM.

Now if we look at message based app, it was last attempted at 4:41 PM and hence it waits until its next polling time comes. The message based logic app was executed at 4:44 PM.

On the other hand, if we look at event based logic app, we can see that it was triggered automatically at 4:42 PM as shown below.

I hope this article has clarified how events are handled and how messages are handled. I am sure you will be able to select appropriate Azure service based on need of your application. Please do comment and let me know your thoughts.

Leave a ReplyCancel reply