86

I'm learning the messaging system and got confused by those terminology.

All the messaging system below provides loose coupling between services with different sets of features.

queue - FIFO, pulling mechanism, 1 consumer each queue but any number of producers?

message bus - pub/sub model, any number of consumers with any number of producers processing messages? Is Azure Service Bus an implementation of message bus?

event bus - pub/sub model, any number of consumers with any number of producers processing events?

Do people use message bus and event bus interchangeably as far as terminology goes?

What are the difference between events and messages? Are those just synonyms in this context?

event hub - pub/sub model, partition, replay, consumers can store events in external storage or close to real-time data analysis. What exactly is event hub?

event grid - it can be used as a downstream service of event hub. What does it exactly do that event hub doesn't do?

Can someone provide some historical context as how each technology evolve to another each tied with some practical use cases?

I've found message bus vs. message queue helpful

jen007
  • 1,389
  • 3
  • 15
  • 19
  • 4
    I do recommend to read the following documents: https://azure.microsoft.com/en-us/blog/events-data-points-and-messages-choosing-the-right-azure-messaging-service-for-your-data/ https://learn.microsoft.com/en-us/azure/event-grid/compare-messaging-services – Roman Kiss Sep 01 '19 at 06:21
  • Unfortunately, that doc leaves some people even more confused than when they started ;-) Esp. those with GCP/AWS background, which are much more clear. I do like Ithar's practical explanation below however. – dan Jul 15 '21 at 19:39
  • Welcome to the world of Azure. Where Microsoft release 10 products that do “almost” the same thing and build an entire eco-system around each one :-( – Robert Perry Apr 18 '23 at 07:46

4 Answers4

135

Even thou all these services deal with the transfer of data from source to target and might seem similar falling under the umbrella messaging services they do differ in their intent.

High-level definition:

  • Azure Event Grids – Event-driven publish-subscribe model (think reactive programming)
  • Azure Event Hubs – Multiple source big data streaming pipeline (think telemetry data)
  • Azure Service Bus- Traditional enterprise broker messaging system (Similar to Azure Queue but provide many advanced features depending on use case full comparison)

Difference between Event Grids & Event Hubs

  1. Event Grids doesn’t guarantee the order of the events, but Event Hubs use partitions which are ordered sequences, so it can maintain the order of the events in the same partition.
  2. Event Hubs are accepting only endpoints for the ingestion of data and they don’t provide a mechanism for sending data back to publishers. On the other hand, Event Grids sends HTTP requests to notify events that happen in publishers.
  3. Event Grid can trigger an Azure Function. In the case of Event Hubs, the Azure Function needs to pull and process an event.
  4. Event Grids is a distribution system, not a queueing mechanism. If an event is pushed in, it gets pushed out immediately and if it doesn’t get handled, it’s gone forever. Unless we send the undelivered events to a storage account. This process is known as dead-lettering.
  5. In Event Hubs the data can be kept for up to seven days and then replayed. This gives us the ability to resume from a certain point or to restart from an older point in time and reprocess events when we need it.

Difference between Event Hubs & Service Bus

To the external publisher or the receiver Service Bus and Event Hubs can look very similar and this is what makes it difficult to understand the differences between the two and when to use what.

  1. Event Hubs focuses on event streaming where Service Bus is more of a traditional messaging broker.
  2. Service Bus is used as the backbone to connects applications running in the cloud to other applications or services and transfers data between them whereas Event Hubs is more concerned about receiving massive volume of data with high throughout and low latency.
  3. Event Hubs decouples multiple event-producers from event-receivers whereas Service Bus aims to decouple applications.
  4. Service Bus messaging supports a message property ‘Time to Live’ whereas Event Hubs has a default retention period of 7 days.
  5. Service Bus has the concept of message session. It allows relating messages based on their session-id property whereas Event Hubs does not.
  6. Service Bus the messages are pulled out by the receiver & cannot be processed again whereas Event Hubs message can be ingested by multiple receivers.
  7. Service Bus uses the terminology of queues and topics whereas Event Hubs partitions terminology is used.

Use this loose general rule of thumb.

SOMETHING HAS HAPPENED – Event Hubs

DO SOMETHING or GIVE ME SOMETHING – Service Bus

As @Louie Almeda stated you may find this link to the official Azure documentation useful.

JuJoDi
  • 14,627
  • 23
  • 80
  • 126
Ithar
  • 4,865
  • 4
  • 39
  • 40
  • 1
    You wrote "Event Grid can trigger an Azure Function. In the case of Event Hubs, the Azure Function needs to pull and process an event.", but I was under the impression that both used a push-mechanism (while Service Bus uses polling). See [Event Hubs Features - Read events](https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-features#read-events). Or am I misinterpreting the docs? – Stanislas Mar 09 '21 at 18:26
  • 2
    This is the first explanation of the difference between EH and SB that has actually made the _usage_ distinction clear to me, as opposed to just listing functional differences. Thank you. – Bobson Jun 09 '21 at 22:10
  • 3
    It seems that Azure Functions support Event Hub as a trigger now: https://learn.microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings?tabs=csharp#supported-bindings – dan Jul 15 '21 at 19:48
  • 2
    Your general rule comment should be at the very top of every page at Microsoft, it is a fast answer to every question :) – user729400 Oct 14 '21 at 08:52
  • 1
    "Service Bus the messages are pulled out by the receiver & cannot be processed again whereas Event Hubs message can be ingested by multiple receivers." Could you please elaborate on that? AFAIK, Service Bus supports topics with multiple subscribers allowing more than one process to elaborate the same message. – Omar Muscatello Oct 29 '21 at 18:50
  • 2
    @OmarMuscatello A subscription to a topic resembles a virtual queue that receives copies of the messages that were sent to the topic. Use a topic if you want each message to be delivered to more than one destination component; but once the message is pulled from the queue it cannot be ingested again. – Ithar Nov 02 '21 at 08:58
  • 1
    "Azure Event Grids – Event-driven publish-subscribe model (think reactive programming)" I think that is `false`. Its publish service. It orchestrates the event and only publish it further. The receiving service is not subscribing (is not coupled to evgd) – Pawel Apr 15 '22 at 14:10
  • 1
    "Azure Service Bus- Traditional enterprise broker messaging system (replaces Azure Queue Storage)" Dont think this is accurate. Azure Queue Storage is alive an well and a different offering then Azure Service Bus. Though when you grow out of Azure Queue, Azure Service Bus might be logical next step at this time they remain separate offerings. – David Jul 29 '22 at 16:14
  • "Azure Service Bus- Traditional enterprise broker messaging system (replaces Azure Queue Storage)" Azure Service Bus Peek will leave the message in the queue. Think this answer might be based on older information and feature offerings. – David Jul 29 '22 at 16:16
  • I think the "loose general rule of thumb" is misleading. I chose Event Hubs because of this where it turned out from the [official comparison documentation](https://learn.microsoft.com/en-us/azure/service-bus-messaging/compare-messaging-services) that there is no such notion of such a rule of thumb. It is perfectly reasonable to choose Service Bus where there is no response required, but there is no big data or distributed data streaming involved. – Neo Jul 03 '23 at 13:54
27

I found this comparison from Azure docs extremely helpful. Here's the key distinction between events and messages.

Event vs. message services

There's an important distinction to note between services that deliver an event and services that deliver a message.

Event

An event is a lightweight notification of a condition or a state change. The publisher of the event has no expectation about how the event is handled. The consumer of the event decides what to do with the notification. Events can be discrete units or part of a series.

Discrete events report state change and are actionable. To take the next step, the consumer only needs to know that something happened. The event data has information about what happened but doesn't have the data that triggered the event. For example, an event notifies consumers that a file was created. It may have general information about the file, but it doesn't have the file itself. Discrete events are ideal for serverless solutions that need to scale.

Series events report a condition and are analyzable. The events are time-ordered and interrelated. The consumer needs the sequenced series of events to analyze what happened.

Message

A message is raw data produced by a service to be consumed or stored elsewhere. The message contains the data that triggered the message pipeline. The publisher of the message has an expectation about how the consumer handles the message. A contract exists between the two sides. For example, the publisher sends a message with the raw data, and expects the consumer to create a file from that data and send a response when the work is done.

Comparison of those different services were also discussed, so be sure to check it out.

Louie Almeda
  • 5,366
  • 30
  • 38
5

I agree with your remarks about overloaded terms, especially with cloud-service marketing jargon....

Historically, I events and messages had more distinct meanings - event was term used to refer to communication within the same process whereas - message referred to communication across different processes.

underwater
  • 191
  • 1
  • 11
3

Regarding the "bus", I can give you some "historical" information, as I learned to be a sound engineer. In a music mixer, you also have a "bus" and "routing" for mixing signals. In the case of a mixer, we are talking about electrical signals, either being in the mix or not!

Regarding the messaging system, think of "bus", "hub" and "grid" to be synonyms! They are all fancy words for the same thing. They are trying to express some kind of transportation system that includes some kind of routing, because you always have producers and consumers - and this can be an N:M relation. Depending on the use case.

A queue is typically a bit different, but its effect can be the same. A queue means something where things are in line, like a queue of people to buy something! (Theatre tickets....)

Nowadays, everything is digital, which in its essence means it can be countable. That's how "messages" came into existance! A music mixer would traditionally mix analogous signals, which are not countable but continuous, so the information would be f.ex. spoken voices or any kind of sound. Today, a "message" means some kind of information package, which is unique and countable. So it is a "thing" you can add to and remove from a queue, or send it to a hub for consumers to consume it.

Don't worry, you'll get used to those terms! I hope I was able to give you an idea.

cslotty
  • 1,696
  • 20
  • 28