Sitemap
SilentTech

#Azure #SystemDesign #SQL #ComputerNetworks This publication is aimed to provide knowledge across various technical aspects.

Service Bus vs Event Grid vs Event Hubs

--

Service Bus = reliable delivery of individual business messages (queue/pub-sub with guarantees)

Event Grid = reactive routing of lightweight event notifications (push, pub/sub for events)

Event Hubs = ingesting and replaying massive streams of events (log-based streaming)

Service Bus — brokered messaging (pull, stateful, transactional)

Built for enterprise integration where messages matter individually such as orders, payments, workflow steps.
Messages sit in a queue/topic until a receiver explicitly completes them, so nothing is lost if a consumer is offline.
Supports transactions, sessions, dead-lettering, scheduled delivery and other features.

Event Grid — reactive event routing (push, fire-and-forget, discrete)

Built for “something happened, send notification to subscriber.”

For Example. a resource is created, a blob is uploaded for such cases Event Grid pushes a small notification to registered handlers (webhooks, Functions, Logic Apps) instantly.
It doesn’t store events for later pickup, Event Grid retries for a while and then gives up. It’s not meant for message payloads with business data — it’s meant for lightweight, high-fan-out notifications.

Event Grid retries a failed HTTP delivery with backoff for up to 24 hours, then dead-letters to a Storage account you configure.

Get Anvesh’s stories in your inbox

Join Medium for free to get updates from this writer.

Event Grid pushes over HTTP, a handler is just an endpoint that accepts a POST.

Before it delivers any events, Event Grid sends a one-time validation event to prove you own the endpoint. You must echo back the validation code.

Event Hubs — event streaming (high-throughput ingestion, replay)

Built for firehoses: telemetry, clickstreams, IoT sensor data, logs — millions of events per second.

Azure Event Hubs is a big-data streaming platform built to ingest millions of events per second.

The core idea is an append-only log. Producers append events to the end, and consumers read forward from a position they track themselves.

Events land in a partitioned, ordered log and are retained for a configurable window (hours to days), so multiple independent consumer groups can read the same stream at their own pace, and even replay from an earlier offset.

We can combine all and form a workflow such as If blob is inserted then event grid is triggered and pushes a message to Service bus, after processing service bus message we can record the event in Event hub for further telemetry.

some good article I found: Azure Event Grid and Event Hubs in .NET: When to Use Each

Thank you for Reading…
Stay tuned for more articles.

--

--

Anvesh
Anvesh

Written by Anvesh

Sr. SW Engineer/ Blogger 🔔Follow me to support my journey on Medium/ 🌐LinkedIn: http://www.linkedin.com/in/anveshsalla

SilentTech
SilentTech

Published in SilentTech

#Azure #SystemDesign #SQL #ComputerNetworks This publication is aimed to provide knowledge across various technical aspects.