Message bus vs. Service bus vs. Event hub vs Event grid

Question

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

Answer 1

Even though 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.

Answer 2

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.

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

Answer 4

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.