Messaging and Event-Driven Architecture on Azure

1. Foundations: Choosing the Right Messaging Primitive

The Three Pillars of Azure Messaging

Azure's messaging portfolio is not a single service with performance tiers — it is three services with fundamentally different guarantees. Azure Service Bus is an enterprise broker for reliable, at-least-once (or exactly-once with sessions) delivery of business-critical commands. Azure Event Grid is a reactive routing fabric that pushes lightweight notifications to dozens of subscribers with sub-second latency. Azure Event Hubs is a distributed commit log that retains events for 1–90 days, enabling independent consumers to replay history at their own pace.

The architectural decision is almost always mechanical: if losing a message is unacceptable, use Service Bus; if you need high-fan-out reactivity, use Event Grid; if you need telemetry ingestion or event replay at millions of events per second, use Event Hubs.

Selecting the Right Service: Decision Matrix

2. Azure Service Bus: Topics, Subscriptions, Sessions, and Dead-Letter Queues

Namespace Architecture and SKU Selection

A Service Bus namespace is the top-level billing unit. The Standard tier uses shared multi-tenant infrastructure and is appropriate for dev/test workloads; it does not support Private Link, geo-DR, or messages larger than 256 KB. The Premium tier provides single-tenant reserved messaging units (MUs), messages up to 100 MB, geo-disaster recovery, Private Link, and customer-managed keys — the minimum acceptable tier for production workloads handling PII or financial data.

SB_NS="messaging-event-prod-eastus2-001"
az servicebus namespace create \
  --name "$SB_NS" --resource-group "$RG_PROD" \
  --sku Premium --capacity 2 \
  --zone-redundant true --minimum-tls-version 1.2
az servicebus topic create \
  --namespace-name "$SB_NS" --name "orders" \
  --enable-duplicate-detection true \
  --duplicate-detection-history-time-window PT10M \
  --enable-ordering true # truncated — see CE-13 lab for full script

Topics and Subscription Filters

Each subscription maintains an independent copy of messages matching its filter rules. Correlation filters match on up to 50 message properties using an optimized hash index — negligible overhead at any subscription count. SQL filters accept arbitrary SQL-92 WHERE clauses but are more expensive to evaluate; benchmark before deploying many SQL-filtered subscriptions on a single topic.

Model your domain events to carry enough metadata as application properties that downstream services can filter without parsing the body. Use the Subject property as a discriminated union for your event type name — all consumers inspect it before deserializing, keeping contracts explicit and filterable at the broker layer.

Sessions for Ordered Processing

Without sessions, a subscription delivers messages to the first available consumer regardless of enqueue order. Sessions tie messages with the same SessionId to a single locked consumer — guaranteeing FIFO within a session while preserving horizontal scalability across different sessions. In .NET, use ServiceBusSessionProcessor with ProcessSessionMessageAsync and store per-session state via sessionArgs.GetSessionStateAsync().

Dead-Letter Queues and Poison Message Handling

Every queue and subscription has an auto-provisioned DLQ at the /$DeadLetterQueue suffix. Messages land there when MaxDeliveryCount is exceeded, TTL expires with dead-lettering enabled, or a filter evaluation throws. A growing DLQ is a leading indicator of systemic failure — deploy a dedicated DLQ consumer per subscription with alerting and a replay mechanism.

3. Azure Event Grid: Custom Topics, Event Filtering, and Push Delivery

Event Grid Architecture and System Topics

Event Grid's programming model has three components: an event source (Azure service or custom topic), an event subscription (routing rule), and an event handler (webhook, Function, Service Bus, Storage Queue, or Event Hubs). System topics are created automatically for supported Azure services; custom topics are first-class resources you create for domain events, authenticated via managed identity.

az eventgrid topic create \
  --name "evgt-orders-prod-eastus2-001" \
  --resource-group "$RG_PROD" --location eastus2 \
  --input-schema cloudeventschemav1_0
az eventgrid event-subscription create \
  --name "order-webhook-subscription" \
  --endpoint "https://api.contoso.com/webhooks/order-events" \
  --included-event-types "com.contoso.orders.placed" \
  --advanced-filter data.orderTotal NumberGreaterThan 100 \
  --max-delivery-attempts 30 --event-ttl 1440

Event Filtering: Basic and Advanced

Event type inclusion is the first filter layer — always declare a specific includedEventTypes list rather than using the wildcard default. The second layer is advanced filters using JSON path expressions (up to 25 clauses per subscription, implicit AND). They operate on data.*, subject, eventType, and other top-level properties.

Webhook Delivery, Retries, and Dead-Lettering

Event Grid retries failed deliveries with exponential backoff for up to 24 hours or until maxDeliveryAttempts is exhausted. Your webhook must handle the subscription validation handshake (echo validationResponse) before receiving events. Dead-lettering for Event Grid requires a Blob Storage container — undeliverable events are written as JSON envelopes with last HTTP response code included.

4. Azure Event Hubs: High-Throughput Streaming with Kafka Protocol

Partitions, Consumer Groups, and the Data Model

Event Hubs is a distributed commit log. Each event hub has a fixed number of immutable partitions — ordered, append-only sequences. A consumer group maintains independent offsets per partition, enabling ten different consumers (analytics, search, cold storage) to read the same stream independently. Partition count equals maximum parallelism within a consumer group and cannot be changed after creation.

az eventhubs namespace create \
  --name "evhns-telemetry-prod-eastus2-001" \
  --sku Premium --enable-kafka true \
  --zone-redundant true
az eventhubs eventhub create \
  --namespace-name "evhns-telemetry-prod-eastus2-001" \
  --name "telemetry-events" \
  --partition-count 32 --message-retention 7
# See CE-14 lab for consumer groups, Capture, and SAS policy setup

Kafka Protocol Compatibility in .NET

Event Hubs exposes a Kafka-compatible endpoint at <namespace>.servicebus.windows.net:9093 using SASL_SSL. Existing Kafka applications can migrate by updating only the broker address and credentials — no application code changes. For greenfield .NET projects, the native Azure.Messaging.EventHubs SDK is preferred for its first-class managed identity integration and OpenTelemetry diagnostics.

Event Processor Client: Checkpointing and Load Balancing

EventProcessorClient manages partition ownership across instances via blob storage lease negotiation and raises ProcessEventAsync per message. Checkpoint frequency is a throughput-vs-reprocessing tradeoff: checkpointing every 100 events or 10 seconds is a practical default. Always checkpoint after a successful downstream write to maintain at-least-once semantics.

5. MassTransit on Azure Service Bus: Saga Orchestration

MassTransit Fundamentals for Azure

MassTransit maps its consumer and saga model onto Service Bus entities automatically — each message type gets a topic/subscription pair, sagas get a dedicated queue. Configure the transport using UsingAzureServiceBus with DefaultAzureCredential for managed identity. Disable AutoStart entity creation in production and pre-create infrastructure via Bicep or the Azure CLI.

builder.Services.AddMassTransit(x => {
    x.AddSagaStateMachine<OrderFulfillmentStateMachine, OrderFulfillmentState>()
        .EntityFrameworkRepository(r => { r.ExistingDbContext<OrderDbContext>(); r.UseSqlServer(); });
    x.UsingAzureServiceBus((ctx, cfg) => {
        cfg.Host(new Uri("sb://messaging-event-prod-eastus2-001.servicebus.windows.net/"),
            h => h.TokenCredential = new DefaultAzureCredential());
        cfg.UseEntityFrameworkOutbox<OrderDbContext>(ctx);
        cfg.UseMessageRetry(r => r.Exponential(5, TimeSpan.FromSeconds(1),
            TimeSpan.FromSeconds(30), TimeSpan.FromSeconds(2)));
        cfg.ConfigureEndpoints(ctx);
    });
});

State Machine Sagas for Long-Running Workflows

A saga coordinates a multi-step workflow (e.g., OrderPlaced → AwaitingPayment → AwaitingFulfillment → Completed) by persisting state and reacting to domain events. MassTransit's EF Core repository against Azure SQL is the standard production choice, enabling transactional outbox integration. For high-throughput scenarios, the Redis repository via Azure Cache for Redis offers lower latency.

Consumer Configuration and Error Handling

MassTransit retry (UseMessageRetry) runs in-process without consuming a Service Bus delivery count — only when MassTransit exhausts its retries does it dead-letter the message and increment the Service Bus count. The circuit breaker filter (UseCircuitBreaker) prevents cascade failures by faulting messages immediately when a downstream dependency is unavailable, allowing the broker to redeliver to other instances.

6. Transactional Outbox Pattern and Idempotency Guarantees

The Dual-Write Problem

It is impossible to atomically update a local database and publish a message to an external broker. Crash-after-write-but-before-publish means the message is never sent; crash-after-publish-but-before-write means the event is emitted without persisted state. The outbox pattern closes this gap: write the message into an OutboxMessage table in the same database transaction as the business data, then relay asynchronously.

MassTransit provides a first-class EF Core outbox: cfg.UseEntityFrameworkOutbox<TDbContext>(ctx) intercepts all Publish and Send calls inside consumers and writes them to the outbox table. A background OutboxDeliveryService sweeps the table and delivers pending messages to Service Bus. Combined with Service Bus duplicate detection keyed on the outbox row ID, the relay is safely retriable.

Implementing the Outbox in .NET with EF Core

Add outbox entities to your DbContext by calling modelBuilder.AddInboxStateEntity(), modelBuilder.AddOutboxMessageEntity(), and modelBuilder.AddOutboxStateEntity() in OnModelCreating. Generate and apply EF migrations to create the three tables. The InboxState table tracks processed message IDs for exactly-once consumer semantics beyond the Service Bus duplicate detection window.

APP_MI_ID=$(az identity show --name "id-orders-api-prod-eastus2-001" \
  --resource-group "$RG_PROD" --query principalId -o tsv)
SB_NS_ID=$(az servicebus namespace show --name "$SB_NS" \
  --resource-group "$RG_PROD" --query id -o tsv)
az role assignment create --assignee "$APP_MI_ID" \
  --role "Azure Service Bus Data Sender" --scope "$SB_NS_ID"
az role assignment create --assignee "$APP_MI_ID" \
  --role "Azure Service Bus Data Receiver" --scope "$SB_NS_ID"

Idempotency at the Consumer Level

Even with an outbox on the producer side, consumer idempotency must be designed explicitly. Store (MessageId, ConsumerType) in a processed-messages table within the same transaction as your business operation. Before processing, check if the key exists and acknowledge without reprocessing if found. Use EF Core's RowVersion property for optimistic concurrency so that concurrent deliveries of the same message result in a concurrency exception (triggering retry) rather than silent data corruption.

7. Lab: Service Bus Topology and Event Hubs Kafka Provisioning

set -euo pipefail
RG_DEV="rg-messaging-event-driven-architecture-dev-001"
SB_NS_DEV="messaging-event-dev-eastus2-001"
az group create --name "$RG_DEV" --location eastus2 \
  --tags Environment=Development Lab=CE-13
az servicebus namespace create --name "$SB_NS_DEV" \
  --resource-group "$RG_DEV" --sku Standard
az servicebus topic create --namespace-name "$SB_NS_DEV" \
  --name orders --enable-duplicate-detection true \
  --default-message-time-to-live P14D
# Add subscriptions and payments topic — see full script in repo

set -euo pipefail
EH_NS_DEV="evhns-telemetry-dev-eastus2-001"
az eventhubs namespace create --name "$EH_NS_DEV" \
  --resource-group "$RG_DEV" --sku Standard \
  --enable-kafka true --capacity 2
az eventhubs eventhub create --namespace-name "$EH_NS_DEV" \
  --name device-telemetry --partition-count 16 \
  --message-retention 3 --enable-capture true
# bootstrap.servers=${EH_NS_DEV}.servicebus.windows.net:9093

8. Summary

Chapter: 7 of 12  |  Status: v0.1 Draft  |  2026-07-08