Azure Service Bus Topology Design

Azure Service Bus is a fully managed enterprise message broker that provides reliable asynchronous messaging between applications. It exists to decouple applications, enabling them to communicate without being directly connected or available at the same time. This improves scalability, resilience, and maintainability. Service Bus supports two primary messaging patterns: queues (point-to-point) and topics (publish/subscribe). It also provides features like message sessions, scheduled delivery, duplicate detection, dead-lettering, and transaction support.

Service Bus operates as a middleware layer. When a sender sends a message, it is stored in a queue or topic until a receiver retrieves it. For queues, each message is delivered to a single consumer (competing consumers pattern). For topics, each subscription receives a copy of the message, and filters can control which messages are delivered to which subscription. Messages are delivered in FIFO order by default, but sessions can enforce strict ordering and grouping.

Using Azure CLI:

# Create a namespace
az servicebus namespace create --name mynamespace --resource-group myrg --location eastus

# Create a queue
az servicebus queue create --namespace-name mynamespace --resource-group myrg --name myqueue --max-delivery-count 5 --default-message-time-to-live P14D

# Create a topic
az servicebus topic create --namespace-name mynamespace --resource-group myrg --name mytopic

# Create a subscription with a SQL filter
az servicebus topic subscription create --namespace-name mynamespace --resource-group myrg --topic-name mytopic --name mysub
az servicebus topic subscription rule create --namespace-name mynamespace --resource-group myrg --topic-name mytopic --subscription-name mysub --name myfilter --filter-sql-expression "sys.Label='urgent'"

# Send a message (using .NET SDK)
// var sender = client.CreateSender("myqueue");
// await sender.SendMessageAsync(new ServiceBusMessage("Hello"));

# Receive a message (using .NET SDK)
// var receiver = client.CreateReceiver("myqueue");
// var message = await receiver.ReceiveMessageAsync();
// await receiver.CompleteMessageAsync(message);

This deep understanding of Service Bus internals and configuration will help you design robust messaging topologies and answer exam questions accurately.

A large e-commerce company uses Service Bus to decouple their web frontend from the order fulfillment backend. When a customer places an order, the frontend sends a message to an orders-queue. The fulfillment service listens on that queue and processes orders. The queue is configured with maxDeliveryCount = 3 and TTL = 7 days. Duplicate detection is enabled with a 5-minute window to prevent duplicate orders due to retries. Sessions are not needed because ordering is independent. The system handles 10,000 orders per minute. They use a Premium namespace with 4 messaging units to meet throughput. A dead-letter queue captures failed orders for manual review. Misconfiguration: If maxDeliveryCount is too high (e.g., 100), poison messages will retry many times, wasting resources. If TTL is too short, legitimate orders may expire before processing during peak times.

A financial services company sends notifications to traders via email, SMS, and mobile push. They use a notifications-topic with three subscriptions: email-sub, sms-sub, and push-sub. Each subscription has a SQL filter based on user preferences stored in message properties (e.g., user.email='true'). The topic is configured with duplicate detection to avoid sending duplicate notifications. Scheduled messages are used for delayed alerts (e.g., market open reminders). They use correlation filters for high-priority alerts to bypass SQL evaluation. The system sends 1 million messages per day. Misconfiguration: If filters are too complex (e.g., multiple joins), they can slow down message delivery. They learned to use correlation filters for simple matching and SQL filters only when necessary.

A global logistics company needs high availability across regions. They deploy two Service Bus namespaces in paired regions (e.g., West US and East US). They use Geo-Disaster Recovery to automatically failover if the primary region goes down. The secondary namespace is passive until failover. They also implement client-side logic to send messages to both namespaces for active-active scenarios, using duplicate detection to handle duplicates. They monitor queue depth and dead-letter counts across both regions. Misconfiguration: Forgetting to configure the failover alias and test it regularly leads to prolonged downtime. They now conduct quarterly DR drills.