This chapter covers event-driven architecture in Azure using Event Grid and Service Bus, two core messaging services. For the AZ-305 exam, understanding when to use each service and how they integrate into solution designs is critical, as approximately 10-15% of questions touch on messaging and event-driven patterns. You will learn the internal mechanisms, key configuration values, and exam-specific traps to avoid.
Jump to a section
Imagine a large corporate mailroom. Event Grid is like a high-speed pneumatic tube system that carries small, time-sensitive memos (events) from any department to any other department instantly. When a memo arrives, the tube system immediately shoots it to all subscribers who signed up for that type of memo. It doesn't store memos; if a recipient is out, the memo is lost. Service Bus is like a secure, lockable mailroom with individual mail slots. Senders deposit letters (messages) into specific slots, and recipients come to pick them up when ready. The mailroom holds letters until the recipient retrieves them, even if the recipient is away for days. It also allows sending a single letter to multiple recipients via a distribution list (topics). The mailroom can hold letters for a configurable time (up to 14 days), and if a recipient doesn't pick up a letter, it can be moved to a dead-letter slot. In this analogy, Event Grid is for broadcast-style event notifications that must be delivered immediately, while Service Bus is for reliable, durable message delivery with advanced patterns like competing consumers and sessions.
What is Event-Driven Architecture?
Event-driven architecture (EDA) is a software design pattern where components communicate by producing and consuming events. An event is a change in state or a significant occurrence, such as 'file uploaded to blob storage' or 'order placed'. The producer emits an event without knowing who will consume it; consumers subscribe to events they care about. This decouples components, improving scalability and resilience.
Azure Event Grid: The Event Backplane
Azure Event Grid is a fully managed event routing service that uses a publish-subscribe model. It is designed for high throughput (up to 5 million events per second per region) and low latency (sub-second delivery). Event Grid supports over 20 Azure services as event sources (e.g., Blob Storage, Resource Groups, Event Hubs) and custom topics for your own applications.
How it works internally: - Producers send events to an Event Grid topic (system or custom). - Each event is a JSON object with required fields: id, eventType, subject, eventTime, data, dataVersion, and metadataVersion. - Event Grid matches the event against event subscriptions based on filters (by event type, subject prefix/suffix, or advanced filters). - It delivers the event to the endpoint (e.g., webhook, Azure Function, Service Bus queue, Event Hubs) via HTTP POST. - Delivery is attempted with exponential backoff retry: first retry after 10 seconds, then 30, then 1 minute, up to 24 hours. After that, events are either dead-lettered or dropped.
Key components: - Topics: Endpoint where publishers send events. Can be system topics (Azure service sources) or custom topics. - Event Subscriptions: Configuration that defines which events to receive and where to send them. Supports filtering and batching. - Event Handlers: Endpoints that process events. Supported: Webhooks, Azure Functions, Azure Service Bus, Azure Event Hubs, Azure Storage Queues, Azure Logic Apps, and more.
Configuration and defaults: - Event retention: 1 day (default) to 7 days for custom topics, 14 days for system topics (max). - Event schema: CloudEvents v1.0 or Event Grid schema. - Batching: Up to 1 MB per batch, configurable batch size (1-5000 events). - Retry policy: Exponential backoff with max 30 retries, configurable.
Azure Service Bus: Enterprise Message Broker
Azure Service Bus is a fully managed message broker designed for reliable, ordered, and durable message delivery. It supports two messaging patterns: queues (point-to-point) and topics (publish-subscribe). It is ideal for enterprise integration, decoupling applications, and handling high-value transactions.
How it works internally: - Producers send messages to a Service Bus namespace, which contains queues or topics. - Messages are stored in the queue/topic until consumed. Each message has a unique MessageId, and can include session IDs, correlation IDs, and custom properties. - For queues, each message is delivered to one consumer (competing consumers pattern). For topics, messages are delivered to all subscriptions that match filters. - Consumers receive messages via long-polling (Peek-Lock mode) or push (ReceiveAndDelete). - In Peek-Lock, the message is locked for a configurable duration (default 60 seconds). After processing, the consumer calls Complete() to remove the message; if it fails, it calls Abandon() or DeadLetter().
Key components: - Namespace: Container for all messaging components. Provides FQDN endpoint. - Queue: FIFO (first-in-first-out) message store. Supports sessions for strict ordering. - Topic: Similar to queue but allows multiple subscriptions with filters. - Subscription: Entity under a topic that receives copies of messages matching its filter. - Dead-letter queue (DLQ): Stores messages that cannot be processed after max delivery count (default 10).
Defaults and values: - Message size: 256 KB (Standard tier), 1 MB (Premium tier). Max 1 MB. - Message time-to-live (TTL): Default 14 days. Max 14 days. - Lock duration: 30 seconds to 5 minutes (default 60 seconds). - Max delivery count: 10 (configurable from 1 to 2000). - Queue/topic partitioning: Enabled by default on Basic/Standard, can be disabled.
Integration of Event Grid and Service Bus
Event Grid can publish events directly to a Service Bus queue or topic. This is useful for reliable event processing: Event Grid provides high-speed event routing, while Service Bus provides durable storage and advanced processing capabilities. For example, you can route Azure Blob Storage events to a Service Bus queue, then process them with a backend service that supports long-running operations.
When to Use Which?
| Scenario | Recommended Service | |----------|-------------------| | High-throughput event broadcasting (e.g., resource group events) | Event Grid | | Reliable, ordered message delivery with transactions | Service Bus | | One-to-one communication with competing consumers | Service Bus Queue | | One-to-many with subscriber-specific filters | Event Grid or Service Bus Topics | | Long-running operations requiring message deferral | Service Bus | | Real-time event processing with low latency | Event Grid |
Exam Traps
Event Grid is not for storing events: It delivers events in near real-time; if no subscriber is available, events are retried then lost. Service Bus persists messages.
Event Grid supports custom topics, but system topics are for Azure services.
Service Bus Premium tier is needed for dedicated resources and larger message sizes (1 MB).
Event Grid cannot directly trigger Azure Functions with HTTP triggers; use Event Grid trigger.
Service Bus sessions are required for strict ordering (FIFO) across multiple messages.
Verification Commands
# Create an Event Grid topic (CLI)
az eventgrid topic create --name my-topic --resource-group my-rg --location eastus
# Create a Service Bus namespace
az servicebus namespace create --name my-ns --resource-group my-rg --location eastus --sku Premium
# Create a Service Bus queue
az servicebus queue create --namespace-name my-ns --resource-group my-rg --name my-queue --max-delivery-count 5Define Event Schema
When building an event-driven solution, first define the event schema. For Event Grid, events must include id, eventType, subject, eventTime, data, dataVersion, and metadataVersion. For Service Bus, messages can be any format (JSON, XML, binary), but best practice is to use a consistent schema with MessageId and custom properties. This step ensures interoperability between producers and consumers.
Create Topic or Queue
Create an Event Grid topic or Service Bus queue/topic in Azure. For Event Grid, use `az eventgrid topic create`. For Service Bus, create a namespace first, then a queue or topic. Choose the tier (Standard vs Premium) based on throughput and feature requirements. Premium provides dedicated resources and larger message sizes.
Configure Subscriptions
For Event Grid, create event subscriptions that define which events to receive and where to send them. You can filter by event type, subject, or use advanced filters. For Service Bus topics, create subscriptions with SQL-like filters (e.g., `CorrelationId = '123'`). This decouples producers from consumers.
Implement Producer
Write code to send events/messages to the topic/queue. For Event Grid, use the Event Grid SDK or REST API. For Service Bus, use the Azure.Messaging.ServiceBus SDK. Ensure authentication via managed identity or connection string. Set properties like TTL, session ID, or correlation ID as needed.
Implement Consumer
Write code to process events/messages. For Event Grid, create an Azure Function with Event Grid trigger or a webhook endpoint. For Service Bus, use a function with Service Bus trigger or a long-running service. Handle Peek-Lock pattern: process message, then call Complete() or DeadLetter() on failure.
Scenario 1: Real-Time Resource Monitoring
A large enterprise uses Azure Resource Groups for each department. They need to monitor resource creation and deletion in real time. They deploy Event Grid with system topics for resource groups. Each department subscribes to events with subject filters (e.g., 'Microsoft.Resources/...') and routes them to a central Azure Function that logs to Log Analytics. This provides near-instant visibility. Initially, they used Service Bus topics, but found latency too high for real-time needs. Event Grid reduced latency to under 1 second. Misconfiguration: forgetting to set proper filters caused all resource events to flood the function, overwhelming it. They added subject prefix filters to limit events.
Scenario 2: Order Processing Pipeline
An e-commerce platform uses Service Bus for order processing. When an order is placed, a message is sent to a queue. Multiple microservices compete to process the order (competing consumers). The queue ensures exactly-once processing via Peek-Lock. If processing fails, the message is retried up to 10 times, then dead-lettered for manual inspection. They use sessions to group all messages for a single order (e.g., order placed, payment processed, shipped) to maintain order. Performance: Premium tier handles 20,000 messages/second. Common issue: forgetting to set session ID causes messages to be processed out of order.
Scenario 3: Hybrid Cloud Integration
A company uses on-premises systems that need to send events to Azure. They use Service Bus Relay (now part of Hybrid Connections) or Event Grid via Azure Arc. They deploy a Service Bus queue in Azure and use the on-premises app to send messages via AMQP. A Logic App in Azure picks up messages and triggers workflows. This provides reliable delivery across cloud boundaries. Misconfiguration: not setting TTL appropriately caused stale messages to pile up. They set TTL to 24 hours for time-sensitive orders.
The AZ-305 exam tests Event Grid and Service Bus under objective 4.4 (Design a messaging solution). Key focus areas:
When to use Event Grid vs Service Bus: The exam presents scenarios and asks which service to use. Trap: Candidates choose Event Grid for reliable delivery with retries, but Event Grid does not guarantee delivery if the endpoint is down for long. Service Bus is for durable, persistent messaging.
Event Grid filtering: Questions on subject filters vs event type filters. Common wrong answer: using event type filter when subject prefix is needed. For example, to get all blob creation events, filter on event type 'Microsoft.Storage.BlobCreated' or subject prefix '/blobServices/default/containers/'.
Service Bus tiers: Standard vs Premium. Trap: Standard supports sessions? Yes, but Premium is needed for dedicated resources, larger message sizes (1 MB), and geo-disaster recovery. Exam may ask which tier supports message sessions (both do).
Dead-lettering: Service Bus DLQ is triggered after max delivery count (default 10). Event Grid also supports dead-lettering to a storage blob, but only after retries are exhausted. Common wrong answer: Event Grid dead-letters immediately on failure. Reality: only after retries.
Event Grid retry policy: Exponential backoff up to 24 hours. Candidates often think retries stop after a few minutes. The exam may ask about max retry time (24 hours).
Service Bus sessions: Required for FIFO ordering. Without sessions, messages are not guaranteed to be processed in order. Exam scenario: you need to process messages in order, so enable sessions.
Authentication: Managed identity vs connection strings. Event Grid uses SAS tokens or managed identity. Service Bus supports managed identity, SAS, and AAD. Exam may ask which is more secure (managed identity).
Geo-disaster recovery: Service Bus Premium supports geo-disaster recovery with active-passive replication. Event Grid supports cross-region failover via custom topics with multiple endpoints.
To eliminate wrong answers, focus on the keyword: 'reliable' implies Service Bus; 'real-time' or 'high throughput' implies Event Grid; 'order' implies Service Bus sessions; 'filter' implies Event Grid or Service Bus topics.
Event Grid is for high-throughput, low-latency event broadcasting; it does not store events persistently.
Service Bus provides durable, ordered, and transactional message delivery; use for reliable enterprise messaging.
Event Grid supports dead-lettering to blob storage after retries are exhausted (max 24 hours).
Service Bus queues support competing consumers; topics support publish-subscribe with filters.
Service Bus sessions are required for strict FIFO ordering across multiple messages.
Event Grid can route events to Service Bus queues/topics for durable processing.
Service Bus Premium tier is needed for dedicated resources, larger messages (1 MB), and geo-disaster recovery.
These come up on the exam all the time. Here's how to tell them apart.
Event Grid
Publish-subscribe event routing with high throughput (5M events/sec).
No message persistence; events are lost if not delivered within retry window.
Sub-second latency, ideal for real-time notifications.
Supports system topics for Azure services and custom topics.
No ordering guarantee; events may arrive out of sequence.
Service Bus
Enterprise message broker with queues and topics.
Durable message storage with configurable TTL (up to 14 days).
Low latency but higher than Event Grid due to persistence.
Supports advanced patterns: sessions, transactions, dead-lettering.
FIFO ordering with sessions; competing consumers for load balancing.
Mistake
Event Grid guarantees delivery of every event.
Correct
Event Grid does not guarantee delivery. If a subscriber endpoint is unavailable, Event Grid retries with exponential backoff for up to 24 hours, then drops the event unless dead-lettering is configured. For guaranteed delivery, use Service Bus.
Mistake
Service Bus queues provide exactly-once delivery by default.
Correct
Service Bus provides at-least-once delivery. With Peek-Lock and Complete(), you can achieve exactly-once processing, but duplicates can occur if the client fails after sending Complete() but before the server removes the message. Use duplicate detection to mitigate.
Mistake
Event Grid can directly trigger any Azure service.
Correct
Event Grid can deliver events to supported handlers only: Azure Functions, Webhooks, Service Bus, Event Hubs, Storage Queues, Logic Apps, and a few others. It cannot directly trigger Azure VMs or SQL databases.
Mistake
Service Bus topics and Event Grid topics are interchangeable.
Correct
They are not. Event Grid is for event broadcasting with high throughput and low latency, but no message persistence. Service Bus topics provide durable, ordered delivery with advanced features like sessions and transactions.
Mistake
Event Grid events are always delivered in order.
Correct
Event Grid does not guarantee order of delivery. Events may arrive out of order. For ordering, use Service Bus with sessions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Event Grid is an event routing service designed for high-throughput, low-latency event broadcasting. It does not persist events; if no subscriber is available, events are retried for up to 24 hours then dropped. Service Bus is a durable message broker that stores messages until consumed, supports ordering via sessions, and provides advanced features like transactions and dead-lettering. Choose Event Grid for real-time notifications, and Service Bus for reliable, ordered message processing.
Yes, Event Grid can deliver events to a Service Bus queue or topic as a handler. This combines Event Grid's high-speed routing with Service Bus's durable storage. For example, you can route Azure Blob Storage events to a Service Bus queue for processing by a backend service that may take longer.
Event Grid uses exponential backoff for retries: first retry after 10 seconds, then 30 seconds, then 1 minute, and so on, up to a maximum of 30 retries over 24 hours. After that, if dead-lettering is configured, the event is sent to a storage blob. Otherwise, it is dropped.
In Service Bus Standard tier, the maximum message size is 256 KB. In Premium tier, it is 1 MB. This includes the message body and properties. For larger payloads, use event sourcing or store the payload in blob storage and pass a reference.
Enable sessions on the queue or topic. Messages with the same session ID are guaranteed to be delivered in order (FIFO) and processed by a single consumer at a time. Without sessions, messages may be processed out of order due to parallel consumers.
The dead-letter queue (DLQ) is a sub-queue that stores messages that cannot be processed normally. Messages are moved to the DLQ when the max delivery count is exceeded (default 10), when they expire (TTL), or when explicitly dead-lettered by the consumer. It allows for manual inspection and reprocessing.
Yes, you can use Event Grid with on-premises systems via Azure Arc or by exposing a public webhook endpoint. However, for hybrid scenarios, Service Bus Relay or Hybrid Connections are often easier to secure. Event Grid also supports private endpoints for secure integration.
You've just covered Event-Driven Architecture with Event Grid and Service Bus — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?