Azure Messaging: Service Bus, Event Grid, Event Hubs, and Reliable Patterns

Service Bus is an enterprise message broker for commands and durable workflows. Event Grid routes discrete events from publishers to handlers. Event Hubs ingests high-throughput event streams for consumers that read partitioned logs. The right choice follows message meaning, delivery guarantees, throughput, ordering, replay, filtering, and consumer behavior.

How do the services differ?

A command asks a specific capability to do something. An event says something already happened. Mixing them produces unclear ownership and retry behavior.

How do you create Service Bus?

Ways to build

Choose the Azure tool you want to use. The underlying resource stays the same.

Azure portalAzure CLI

Azure portal

Open Service Bus → Create namespace, choose tier, region, zone/network options, identity, encryption, and tags. Then create a queue or topic/subscription with TTL, lock duration, duplicate detection, sessions, max delivery count, and dead-letter behavior.

Azure CLI

bash

WrapCopy

SB_NAMESPACE="sb-northstar-REPLACE_UNIQUE" az servicebus namespace create \ --resource-group "$AZURE_RG" \ --name "$SB_NAMESPACE" \ --location "$AZURE_LOCATION" \ --sku Standard az servicebus queue create \ --resource-group "$AZURE_RG" \ --namespace-name "$SB_NAMESPACE" \ --name document-indexing \ --max-delivery-count 10 \ --enable-dead-lettering-on-message-expiration true

Grant sender and receiver data roles to separate managed identities. Do not distribute a namespace-wide shared access key to every application.

How do reliable consumers work?

1. Receive with a lock/lease.
2. Validate schema and authorization context.
3. Perform idempotent processing.
4. Complete only after durable success.
5. Abandon/retry transient failure with bounded backoff.
6. Dead-letter permanent or exhausted failures with a reason.
7. Alert on queue age, backlog, failures, and dead-letter growth.

Exactly-once business outcomes normally require application idempotency, not faith in a transport label. Store a message or operation ID with the result.

How do Event Grid and Event Hubs change the model?

Event Grid pushes events and retries according to its delivery policy. Use filters and dead-letter destinations. Handlers should return quickly, validate the event, and enqueue long work.

Event Hubs consumers track offsets/checkpoints per partition. Partition keys preserve order within a partition, not across the entire hub. Consumer groups provide independent views. Capture can write streams to storage for later analytics.

How do you manage event schemas?

Use a versioned envelope with event ID, type, source, subject/entity, time, schema version, correlation/causation IDs, tenant where relevant, and data. Add optional fields compatibly. Avoid repurposing existing fields. Protect sensitive data because messages are copied to brokers, logs, dead letters, and analytics stores.

IaC and network design

Bicep/Terraform should declare namespaces/topics/queues/hubs, authorization via RBAC, identities, private endpoints, DNS, diagnostic settings, dead-letter destinations, retention, capacity, and alerts. Premium/dedicated options have different network and throughput features. Check current tier matrices.

Decision questions

• Is this a command, event, or stream record?
• Must consumers replay history?
• Where is ordering required?
• What is the maximum payload and throughput?
• Can the consumer process duplicates?
• How are poison messages inspected and replayed?
• What happens when a downstream dependency is unavailable for hours?

Official references

• Azure Service Bus
• Azure Event Grid
• Azure Event Hubs
• Asynchronous messaging options