Azure Event Hubs

Azure Event Hubs is a big-data streaming platform and event ingestion service. It can receive and process millions of events per second with low latency, making it the go-to service for telemetry, analytics pipelines, and real-time stream processing on Azure. This lesson covers the architecture of Event Hubs, how to send and receive events, and the pricing tiers available.

---

What Makes Event Hubs Different

Event Hubs is fundamentally different from Service Bus and Event Grid. While Service Bus is a message broker (routing individual messages to consumers) and Event Grid is an event router (delivering discrete events to handlers), Event Hubs is a distributed streaming platform — conceptually similar to Apache Kafka.

Key differences:

Aspect	Service Bus	Event Grid	Event Hubs
Model	Message broker	Event router	Streaming platform
Delivery	Push to consumers	Push to handlers	Pull from partitions
Retention	Until consumed	Retry window	Time-based (1–90 days)
Throughput	Thousands/sec	Millions/sec (lightweight)	Millions/sec (data-heavy)
Consumer model	Competing consumers	Subscriptions	Consumer groups + partitions
Message consumption	Destructive (removed after complete)	Delivery-based	Non-destructive (offset-based reads)

Event Hubs retains events for a configurable period. Consumers read from a position (offset) in the stream — they do not delete events by consuming them.

---

Core Architecture

An Event Hubs architecture has four main components:

1. Namespace

A namespace is a container for one or more event hubs. It provides:

• A DNS endpoint (sb-demo-ns.servicebus.windows.net)
• Shared authentication (SAS keys or Entra ID)
• Throughput units or processing units for capacity management

2. Event Hub

An event hub is a named stream of events, analogous to a Kafka topic. Each event hub contains one or more partitions.

3. Partitions

Partitions are the fundamental unit of parallelism. Each partition is an ordered, append-only log:

Event Hub: telemetry
├── Partition 0: [ e1, e2, e3, e4, e5, ... ]
├── Partition 1: [ e6, e7, e8, e9, ... ]
├── Partition 2: [ e10, e11, e12, ... ]
└── Partition 3: [ e13, e14, e15, ... ]

• Events are assigned to partitions by partition key (hash-based) or round-robin (if no key is specified)
• Each partition can be read independently, enabling parallel processing
• The number of partitions is set at creation time (2–32 for Standard, up to 2,048 for Dedicated)

4. Consumer Groups

A consumer group is a view of the entire event hub. Each consumer group tracks its own read position across all partitions:

Event Hub: telemetry
├── Consumer Group: analytics (offset: 500, 300, 450, 200)
├── Consumer Group: archival (offset: 500, 300, 450, 200)
└── Consumer Group: alerting (offset: 498, 295, 440, 195)

Multiple consumer groups can read the same stream independently without interfering with each other. Every event hub has a $Default consumer group.

---

Creating an Event Hub