EVENT HUB VS SERVICE BUS
Event Hub vs. Service Bus

azureservicebus - Message bus vs. Service bus vs. Event hub vs Event grid - Stack Overflow

https://azure.microsoft.com/en-us/blog/events-data-points-and-messages-choosing-the-right-azure-messaging-service-for-your-data/

Asynchronous messaging options - Azure Architecture Center | Microsoft Learn

Related patterns

Consider these patterns when implementing asynchronous messaging:

  • Competing Consumers Pattern. Multiple consumers may need to compete to read messages from a queue. This pattern explains how to process multiple messages concurrently to optimize throughput, to improve scalability and availability, and to balance the workload.
  • Priority Queue Pattern. For cases where the business logic requires that some messages are processed before others, this pattern describes how messages posted by a producer that have a higher priority can be received and processed more quickly by a consumer than messages of a lower priority.
  • Queue-based Load Leveling Pattern. This pattern uses a message broker to act as a buffer between a producer and a consumer to help to minimize the impact on availability and responsiveness of intermittent heavy loads for both those entities.
  • Retry Pattern. A producer or consumer might be unable connect to a queue, but the reasons for this failure may be temporary and quickly pass. This pattern describes how to handle this situation to add resiliency to an application.
  • Scheduler Agent Supervisor Pattern. Messaging is often used as part of a workflow implementation. This pattern demonstrates how messaging can coordinate a set of actions across a distributed set of services and other remote resources, and enable a system to recover and retry actions that fail.
  • Choreography pattern. This pattern shows how services can use messaging to control the workflow of a business transaction.
  • Claim-Check Pattern. This pattern shows how to split a large message into a claim check and a payload.

From <https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/messaging>

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.
  1. 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 ' Even Hubs

DO SOMETHING or GIVE ME SOMETHING ' Service Bus

 

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.

From <https://stackoverflow.com/questions/57740782/message-bus-vs-service-bus-vs-event-hub-vs-event-grid>