1. Events vs Messages — The Fundamental Distinction
Events are lightweight notifications that something happened. The publisher has no expectation about how the event is handled. Events carry minimal data (or a reference) and fan-out to many subscribers.
Messages are payloads containing data the producer explicitly sends to a consumer for processing. There's a contract: the sender expects the message to be acted upon, often with guaranteed delivery and ordering.
| Event | Message | |
|---|---|---|
| Intent | Notify — "this happened" | Command — "do this" |
| Coupling | Loose (pub/sub) | Tighter (sender → receiver) |
| Delivery | At-least-once, fan-out | Guaranteed, ordered |
| Azure service | Event Grid / Event Hubs | Service Bus / Storage Queues |
2. Azure Event Grid — Reactive Event Routing
Event Grid is a fully managed event routing service. It connects event sources to handlers using a push-based, pub/sub model with sub-second latency.
Core Concepts
- System Topics — built-in events from Azure services (Blob Storage, Resource Groups, Subscriptions, IoT Hub).
- Custom Topics — your own application events published via HTTP POST.
- Event Subscriptions — route events to handlers (Functions, Logic Apps, Webhooks, Event Hubs, Service Bus).
- Filters — subject prefix/suffix, event type, or advanced field-level filters to reduce noise.
- Schemas — Event Grid schema, CloudEvents v1.0, or custom input schema with mapping.
Key Characteristics
- Per-event pricing (~$0.60 / million operations) — extremely cost-effective for sparse events.
- Built-in retry with exponential back-off + dead-letter to Blob Storage.
- 10 M events/sec/topic throughput; 24-hour retry window.
3. Azure Event Hubs — High-Throughput Streaming
Event Hubs is a big-data streaming platform ingesting millions of events per second. Think of it as Azure's Apache Kafka equivalent.
Core Concepts
- Partitions — ordered, append-only logs (2–32 in Standard; up to 2,000 in Premium/Dedicated). Events are distributed by partition key.
- Consumer Groups — independent views of the event stream. Each group maintains its own offset.
- Throughput Units (Standard) — 1 TU = 1 MB/s ingress, 2 MB/s egress. Auto-inflate up to 20 TU.
- Capture — automatic export of raw events to Blob Storage or Data Lake in Avro format (zero-code archival).
- Kafka endpoint — wire-compatible with Apache Kafka; no code changes for Kafka producers/consumers.
4. Decision Matrix — Event Grid vs Event Hubs vs Service Bus
| Criterion | Event Grid | Event Hubs | Service Bus |
|---|---|---|---|
| Primary purpose | Reactive event routing | Big-data streaming | Enterprise messaging |
| Delivery model | Push (HTTP/webhook) | Pull (consumer reads) | Pull (peek-lock/receive) |
| Throughput | 10 M events/sec | Millions/sec (partitioned) | Thousands/sec |
| Ordering | No guarantee | Per-partition FIFO | Per-session FIFO |
| Retention | 24 h retry | 1–90 days (log) | Up to 14 days (queue) |
| Protocol | HTTP, CloudEvents | AMQP, Kafka, HTTPS | AMQP, HTTP |
| Pattern | Discrete reactive events | Continuous telemetry stream | Transactional commands |
| Dead-letter | Blob Storage | N/A (replay from offset) | Built-in DLQ |
| When to use | Azure resource events, serverless glue | IoT, logs, analytics feeds | Order processing, workflows |
5. Patterns & Pipelines
Event Grid Patterns
- Resource events — Blob created triggers image resizing Function; VM deallocated notifies ops via Logic App.
- Custom domain events — OrderPlaced event fans-out to inventory, billing, and notification services.
- CloudEvents schema — portable eventing format for multi-cloud or hybrid scenarios.
Event Hubs Patterns
- Telemetry ingestion — millions of IoT sensor readings funneled into partitioned stream.
- Log aggregation — centralize application logs from microservices; Capture to Data Lake for batch analytics.
- Real-time analytics pipeline — Event Hubs → Stream Analytics (windowed aggregations) → Power BI dashboard.
- Event Hubs + Spark — Azure Databricks Structured Streaming reads directly from Event Hubs for ML feature pipelines.
6. Real-World: IoT Platform Architecture
Scenario — Smart Building Platform
A facilities company monitors 50,000 sensors (temperature, occupancy, energy) across 200 buildings.
Architecture
- Event Hubs (telemetry) — sensors send readings every 5 seconds via AMQP. 32 partitions with building-ID as partition key. Capture archives raw data to Data Lake hourly.
- Stream Analytics — windowed queries detect anomalies (temperature > threshold for 5 min) and write alerts to a Service Bus queue for dispatch.
- Event Grid (lifecycle) — IoT Hub raises device-connected/disconnected events → Event Grid → Function updates device registry in Cosmos DB.
- Event Grid (storage) — Blob Created events from Capture files trigger a Databricks notebook for daily batch ML training.
Why Two Services?
Event Hubs handles the firehose (continuous, ordered, high-volume). Event Grid handles the discrete lifecycle events (sparse, reactive, fan-out). Using both keeps costs low and architecture clean.
7. Exam Tip
🎯 AZ-305 loves "which service?" questions. Quick rules:
- "React to Azure resource changes" → Event Grid
- "Ingest millions of telemetry events / streaming" → Event Hubs
- "Guaranteed delivery, dead-letter, transactions" → Service Bus
- "Simple decoupling, low cost, small scale" → Storage Queues
If the question mentions partitions, consumer groups, or Kafka — it's Event Hubs. If it mentions subscriptions with filters, topics in a pub/sub messaging context with sessions — it's Service Bus Topics.
8. Knowledge Check
Q1: A storage account emits a BlobCreated event that should trigger an Azure Function. Which service routes this event?
Q2: An IoT solution ingests 2 million sensor events per second and needs 7-day replay. Which service fits?
Q3: What is the key difference between an event and a message?
Q4: You need Event Hubs data automatically archived to Data Lake with no custom code. Which feature do you enable?