Cloud / Azure Service Bus Interview questions

Azure Service Bus is a fully managed enterprise message broker. Applications send messages to it, and other applications pick them up later, so the two sides never have to be online at the same time or know anything about each other.

It offers queues for point-to-point messaging and topics for publish/subscribe. On top of that you get dead-lettering, sessions for ordering, transactions, duplicate detection and scheduled delivery, which is why it is the usual pick for business-critical flows like order processing.

Clients connect to a namespace endpoint such as myns.servicebus.windows.net over AMQP 1.0 or HTTPS.

Service Bus has a small set of building blocks. Everything lives inside a namespace.

• Namespace - the container and endpoint that holds all your entities.
• Queue - stores messages for a single logical consumer (point-to-point).
• Topic - accepts messages from publishers and fans them out.
• Subscription - a virtual queue under a topic that receives copies of matching messages.
• Rule - a filter (and optional action) that decides which topic messages a subscription gets.

Each queue and subscription also has a built-in dead-letter sub-queue for messages that cannot be processed.

A queue is a durable, broker-hosted buffer that delivers each message to one consumer. Senders add messages at one end, and receivers take them from the other, normally in first-in-first-out order.

If several receivers listen on the same queue they act as competing consumers: each message goes to exactly one of them, so you scale processing just by adding receivers.

Because the queue stores messages until they are settled, it also smooths out traffic spikes. This is called queue-based load leveling.

A topic is the publish side of publish/subscribe messaging. A sender posts one message to the topic and does not care who reads it.

Each subscription on the topic behaves like its own virtual queue. It receives a copy of every message that passes its rules, and consumers read from the subscription independently, at their own speed.

For example, an OrderPlaced topic can feed a billing subscription, a shipping subscription and an analytics subscription, with no change on the publisher.

Service Bus comes in three tiers, chosen per namespace.

Premium also adds private endpoints, VNet integration, geo-disaster recovery, customer-managed keys and predictable latency. Use Basic for simple queues, Standard for most apps that need topics, and Premium when isolation or throughput guarantees matter.

A namespace is the top-level container for your Service Bus queues and topics. It gives you a unique fully qualified domain name, <name>.servicebus.windows.net, which clients use to connect.

Many settings are decided at this level: the pricing tier, region, network rules, encryption options and namespace-wide shared access policies. Entities inside it inherit that environment.

A common practice is to keep one namespace per environment or per bounded workload, so one noisy workload cannot affect another.

Namespace names are globally unique, and access control can be applied here or narrowed down to a single queue, topic or subscription.

A message has a body (opaque bytes, often JSON) plus two kinds of metadata.

• System properties - MessageId, CorrelationId, SessionId, ReplyTo, Subject, ContentType, TimeToLive, ScheduledEnqueueTime, PartitionKey.
• Broker-assigned - SequenceNumber, EnqueuedTime, DeliveryCount, LockToken.
• Application properties - your own key/value pairs, handy for routing and filters.

The broker never inspects the body, so filters work on the properties.

Keep the body small. Anything you need for routing, such as region or message type, belongs in application properties so filters never have to parse the payload.

Receivers pick a settlement behavior when they connect.

Peek-lock is the right choice for almost every business workload.

In peek-lock mode the app must settle every message. If it forgets, the lock expires and the message returns, so always complete or abandon in a finally-style path.

Every queue and subscription has a secondary sub-queue, the dead-letter queue (DLQ), where messages that cannot be delivered or processed are parked instead of being lost.

The path is <queue>/$deadletterqueue, or <topic>/Subscriptions/<sub>/$deadletterqueue for subscriptions.

The broker moves messages there when MaxDeliveryCount is exceeded or, if enabled, when the TTL expires. Applications can also dead-letter explicitly with a reason and description. Nothing purges the DLQ automatically, so you must monitor and drain it.

A message dead-lettered by the broker carries DeadLetterReason and DeadLetterErrorDescription properties, so you can see why it failed without opening logs.

TTL is how long a message may stay in an entity before it expires. Each queue or subscription has a DefaultMessageTimeToLive, and a sender can set a shorter TimeToLive on an individual message.

If a message-level TTL is longer than the entity default, the entity value wins. Once a message expires, it is silently dropped, unless dead-lettering on expiration is enabled, in which case it moves to the DLQ.

Short TTLs suit time-sensitive data like OTP codes or price quotes that are useless if delivered late.

A scheduled message is sent now but becomes visible to receivers only at a future time. You set ScheduledEnqueueTime on the message, or call ScheduleMessageAsync.

The call returns a sequence number. If plans change, pass that number to CancelScheduledMessageAsync before the time arrives.

Typical uses are reminder emails, delayed retries with back-off, and timeouts in long-running workflows.

A scheduled message sits invisible in the entity until its time arrives, then behaves like any other message. It still counts toward entity size while waiting, so very large scheduled backlogs can use up quota.

Deferral lets a receiver set a message aside when it cannot handle it yet, for example when messages arrive out of business order. The message stays in the queue but is skipped by normal receive calls.

The app calls DeferMessageAsync and must remember the SequenceNumber. Later it fetches the message with ReceiveDeferredMessageAsync using that number.

Deferred messages are still subject to TTL, and if the sequence number is lost there is no easy way to find them again.

Deferral differs from abandon: abandoning makes the message immediately deliverable again, while deferral hides it from normal receives until you ask for it by number.

Sessions group related messages so they are handled together and in order. The sender stamps every related message with the same SessionId, for example an order ID or customer ID.

A receiver accepts a session and takes an exclusive lock on it. While it holds the lock, it gets that session's messages in FIFO order, and no other receiver can read them. Sessions also carry session state, a small blob for storing progress.

The queue or subscription must be created with sessions enabled, which requires the Standard or Premium tier.

Create a ServiceBusClient, get a sender for the entity, and call SendMessageAsync. Prefer Microsoft Entra credentials over connection strings.

A single send is limited by the tier's message size (256 KB on Standard). The sender should be created once per entity and shared, since it holds an AMQP link.

await using var client = new ServiceBusClient(
    "myns.servicebus.windows.net", new DefaultAzureCredential());

ServiceBusSender sender = client.CreateSender("orders");

var msg = new ServiceBusMessage(JsonSerializer.Serialize(order))
{
    MessageId = order.Id.ToString(),
    ContentType = "application/json",
    Subject = "OrderCreated"
};
await sender.SendMessageAsync(msg);

For many messages, use CreateMessageBatchAsync and TryAddMessage instead. Create the client once and reuse it.

ServiceBusProcessor is the recommended way to consume messages. It runs a receive loop, calls your handler, renews locks and handles retries on transient errors.

var processor = client.CreateProcessor("orders", new ServiceBusProcessorOptions
{
    MaxConcurrentCalls = 8,
    AutoCompleteMessages = true
});

processor.ProcessMessageAsync += async args =>
{
    var body = args.Message.Body.ToString();
    await HandleAsync(body);          // throw to abandon
};
processor.ProcessErrorAsync += args =>
{
    Console.WriteLine(args.Exception);
    return Task.CompletedTask;
};

await processor.StartProcessingAsync();

If the handler returns normally, the message is completed. If it throws, the message is abandoned and retried.

Duplicate detection makes the broker drop a message if another message with the same MessageId was already accepted within a time window. It protects you when a sender retries after a timeout and ends up sending twice.

It must be turned on when the queue or topic is created. The history window defaults to 10 minutes and can range from 20 seconds to 7 days.

The duplicate is accepted by the API but silently discarded, so the sender sees no error. Choose a stable ID, such as the business key, not a random GUID per attempt.

There are two options.

1. Microsoft Entra ID - assign a role such as Azure Service Bus Data Sender, Data Receiver or Data Owner to a user or managed identity. No secret is stored.
2. Shared Access Signature (SAS) - a policy with Send, Listen and/or Manage rights produces keys, connection strings or time-limited tokens.

Entra ID is the recommended option for production. You can even disable SAS (local auth) on the namespace to enforce it.

Scope matters. Assigning a role at queue level gives an app access to that queue only, rather than the whole namespace.

A subscription rule has a filter that decides whether a topic message is copied to that subscription, and an optional action that can modify properties on the copy.

New subscriptions get a $Default rule with a true filter, so they receive all messages until you replace it.

Rule actions run on the copy only. For example, a SQL action can set a property such as routed=true without changing the message other subscriptions see.

A queue delivers each message to one logical consumer. A topic delivers a copy to every subscription whose filter matches.

If one subscription is enough, a queue is simpler. Pick a topic when several systems must react to the same event.

One more difference is cost and operations: every subscription adds its own storage and delivery work, so a topic with many subscriptions costs more than a single queue.

Both queue messages, but Service Bus is a full broker while Storage Queues is a simple, very large, low-cost queue.

Choose Storage Queues for simple background jobs and huge backlogs. Choose Service Bus when you need ordering, pub/sub, or reliable enterprise semantics.

Also consider message lifetime. Storage Queue messages are removed on delete, while Service Bus gives you explicit complete, abandon, defer and dead-letter outcomes, which matters for auditing failures.

Match the service to the intent of the message.

Use Service Bus when you need guaranteed processing, ordering, dead-lettering or transactions. Use Event Hubs for streaming analytics, and Event Grid for lightweight event routing.

They are often combined. For example, Event Hubs ingests raw telemetry, a processor turns interesting readings into commands, and Service Bus delivers those commands reliably to workers.

If the receiver neither completes nor abandons the message before the lock expires, the broker releases it and makes it available again. The DeliveryCount goes up by one.

The original receiver's later CompleteMessageAsync call fails with a lock-lost error, so the work it did may be repeated by another consumer.

The default lock duration is 1 minute, with a maximum of 5 minutes. ServiceBusProcessor renews the lock automatically up to MaxAutoLockRenewalDuration, so long handlers should raise that value rather than just extending the lock.

A practical rule: set lock duration just above the typical handling time, let the processor auto-renew for slow outliers, and keep handlers idempotent because a redelivery may still occur.

There are a few paths into the DLQ.

• MaxDeliveryCountExceeded - the message was delivered the maximum number of times (default 10) without being completed.
• TTLExpiredException - the TTL elapsed and dead-lettering on expiration is enabled.
• Explicit - your code calls DeadLetterMessageAsync with a reason and description, e.g. for a malformed payload.
• Filter errors - on subscriptions, a rule evaluation failure if that option is on.

The reason and description are stored as properties on the dead-lettered message, which makes triage far easier.

The delivery count decides the first case, so a handler that throws on every attempt reaches the DLQ after ten tries by default, which is why poison messages stop looping.

Open a receiver on the dead-letter sub-queue, inspect why each message failed, then fix, resubmit or discard it.

Many teams run a small repair tool or Function that reads the DLQ, logs the reason, and resubmits messages after a bug fix. Always alert on the DLQ count so this does not go unnoticed.

var dlq = client.CreateReceiver("orders",
    new ServiceBusReceiverOptions { SubQueue = SubQueue.DeadLetter });

await foreach (var m in dlq.ReceiveMessagesAsync())
{
    var reason = m.DeadLetterReason;
    var detail = m.DeadLetterErrorDescription;
    // log, repair payload, then resend a NEW message
    await sender.SendMessageAsync(new ServiceBusMessage(m));
    await dlq.CompleteMessageAsync(m);
}

Resend as a new message rather than trying to move the old one, and complete the DLQ copy only after the resend succeeds. Dead-letter messages count against the entity's size quota.

Strict FIFO is guaranteed per session. The sender sets the same SessionId on related messages and sends them in order. The receiver locks that session and processes it sequentially.

Without sessions, a queue delivers roughly in order, but with several competing consumers, retries or abandons, completion order is not guaranteed.

The sender side matters too. Send ordered messages from one sender sequentially, rather than firing concurrent async sends that can arrive swapped.

If you need both order and scale, use many sessions. Each session is ordered, while different sessions run in parallel across receivers. Also enable duplicate detection if senders may retry, so a repeated send cannot insert a message twice into the ordered stream.

A correlation filter matches by equality on one or more properties, such as Subject, CorrelationId or a custom property. All listed conditions must match (logical AND).

It is cheaper for the broker to evaluate than a SQL expression, so it scales better when a topic has many subscriptions. SQL filters are still the choice when you need LIKE, IN, comparisons or OR logic.

When a filter combines region and message type, correlation filters can match both with a single rule, which stays cheap even with hundreds of subscriptions.

await admin.CreateRuleAsync("orders", "eu-sub",
    new CreateRuleOptions("EuOnly", new CorrelationRuleFilter {
        ApplicationProperties = { ["region"] = "EU" } }));

Auto-forwarding makes the broker automatically move messages from a queue or subscription to another queue or topic in the same namespace. You set ForwardTo on the source.

It is useful for fan-in (many subscriptions into one queue), for chaining a subscription to a queue to get a single consumer, and for separating a processing pipeline into stages.

Chains can be up to four hops deep. The identity that creates the forwarding needs Send permission on the destination, and ForwardDeadLetteredMessagesTo can do the same for dead-lettered messages.

Typical example: a topic with several subscriptions, each forwarded to its own queue, so each service can use queue features like sessions or independent dead-letter handling.

A transaction groups several operations - receive, complete, send, defer, dead-letter - so they either all succeed or all roll back. In .NET you wrap them in a TransactionScope with async flow enabled.

Because the work is committed together, a failed send after a complete rolls the complete back, and the original message stays available for retry. Keep transactions short, since they hold locks.

using var ts = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled);
await receiver.CompleteMessageAsync(msg);
await sender.SendMessageAsync(next);
ts.Complete();

Operations can span entities in the same namespace when EnableCrossEntityTransactions is set. They cannot span namespaces or include your database, which is why patterns like the outbox exist.

Partitioning spreads an entity across several message brokers and stores, which raises throughput and improves availability, because one failing partition does not take the whole entity down.

A message is placed in a partition based on PartitionKey, then SessionId, then MessageId. Ordering is therefore guaranteed only within a partition, so use a key when related messages must stay together.

The setting is fixed at creation time. In Premium, partitioning is configured when the namespace is created.

Partitioning also avoids a single hot broker, but it adds a constraint: you cannot rely on global ordering, so use a stable key when messages for one entity must stay together.

Standard is multi-tenant, so latency and throughput can vary with neighbors. Premium gives you dedicated resources measured in messaging units (1, 2, 4, 8 or 16).

• Predictable latency and throughput for production-critical loads.
• Messages larger than 256 KB, up to 100 MB.
• Private endpoints, VNet rules and customer-managed keys.
• Geo-disaster recovery and availability zones.
• JMS 2.0 for Java applications.

The trade-off is cost: Premium bills per messaging unit per hour even if idle. Stay on Standard for dev/test and modest workloads.

A simple decision rule: if you need private networking, large messages, or a latency guarantee, choose Premium. Otherwise Standard is usually the better value.

The client sends a request to a queue and tells the service where to answer.

1. Client creates a reply queue (or uses a session) and sets ReplyTo to it.
2. Client sets MessageId on the request.
3. Service processes it and replies to the ReplyTo entity, copying the request ID into CorrelationId.
4. Client matches the reply by CorrelationId.

With many clients sharing one reply queue, set ReplyToSessionId so each client receives only its own replies.

Set a TimeToLive on requests. If the service is down, stale requests expire instead of piling up and answering clients that already timed out.

sequenceDiagram
  Client->>RequestQueue: Request (MessageId=42, ReplyTo=replies)
  RequestQueue->>Service: Deliver
  Service->>Replies: Response (CorrelationId=42)
  Replies->>Client: Match by CorrelationId

Standard allows 256 KB per message, including headers. Premium goes to 100 MB. If the payload is bigger, or you want to keep the broker lean, use the claim-check pattern.

1. Upload the large payload to Blob Storage.
2. Send a small Service Bus message containing the blob URI and metadata.
3. The consumer reads the message, downloads the blob, then processes it.

Remember to clean up blobs after completion, for example with a lifecycle policy. Compressing JSON before sending is another cheap win for payloads just over the limit.

Also ensure the consumer can reach the storage account with a managed identity, and treat the blob and the message as one unit when handling failures.

Layer identity, network and data protection.

• Identity - use Entra ID with managed identities and the Data Sender/Receiver roles. Disable SAS (local auth) if you do not need it.
• Least privilege - if SAS is required, use entity-level policies with only Send or Listen, never the root Manage key.
• Network - use private endpoints, VNet rules and IP firewall rules (Premium).
• Encryption - TLS in transit, encryption at rest, and customer-managed keys on Premium.

Rotate any SAS keys and keep them out of source control.

Review access regularly. Entra role assignments can be audited, while shared keys leave no per-identity trail.

When an entity hits its size quota, new sends fail with a quota exceeded error. Existing messages are not lost, and receivers can still read and complete messages, which frees space.

Dead-lettered messages and scheduled messages count toward the size too, so a forgotten DLQ can fill a queue silently.

Fixes: scale out consumers, drain the DLQ, set a sensible TTL, raise the size limit, or use partitioning or Premium for more headroom. Senders should treat this error as a back-pressure signal and retry with back-off.

Monitor the Size metric and alert at around 80 percent, so you can react before senders start failing.

A ServiceBusTrigger runs your function whenever messages arrive in a queue or subscription. The Functions runtime uses peek-lock: success completes the message, an unhandled exception abandons it.

Functions scale out automatically as the backlog grows, but remember the downstream limit. A flood of parallel executions can overwhelm a database, so cap concurrency in host.json. Poison messages end in the dead-letter queue, so add an alert there.

[Function("ProcessOrder")]
public async Task Run(
    [ServiceBusTrigger("orders", Connection = "SbConn")] ServiceBusReceivedMessage msg,
    ServiceBusMessageActions actions)
{
    await HandleAsync(msg.Body.ToString());
    await actions.CompleteMessageAsync(msg);
}

Tune maxConcurrentCalls and maxAutoLockRenewalDuration in host.json. For session queues set isSessionsEnabled. Repeated failures end in the DLQ once the delivery count is exhausted.

Peek-lock gives at-least-once delivery. A lock can expire, a consumer can crash after doing work but before completing, or a sender can retry, so the same message can be processed twice.

An idempotent consumer produces the same result no matter how many times it sees a message. Techniques:

• Store processed MessageId values and skip repeats.
• Use upserts or natural keys instead of blind inserts.
• Use conditional updates, e.g. with a version or ETag.
• Make external calls safe with idempotency keys.

Duplicate detection on the entity helps on the send side, but it does not remove the need for idempotent handlers.

When a receiver pulls a message in peek-lock mode, the broker does not delete it. It locks it for LockDuration, hides it from other receivers, increments DeliveryCount and hands over a LockToken.

The receiver then settles the message with one of four outcomes:

• Complete - the broker deletes it.
• Abandon - the lock is released and the message is immediately available again.
• Defer - it stays in the entity but is only retrievable by sequence number.
• Dead-letter - it moves to the DLQ with a reason.

If no settlement arrives before the lock expires, the broker behaves as if it was abandoned. Settlement must happen on the same link that received the message, so a dropped connection invalidates the lock token.

sequenceDiagram
  Receiver->>Broker: Receive
  Broker-->>Receiver: Message + LockToken (DeliveryCount+1)
  alt Complete
    Receiver->>Broker: Complete
    Broker-->>Broker: Delete message
  else Abandon or lock expired
    Broker-->>Broker: Release, redeliver
  else Dead-letter
    Receiver->>Broker: DeadLetter(reason)
  end

With sessions, the unit of work is the session, not the message.

1. The sender sets the same SessionId on related messages.
2. ServiceBusSessionProcessor asks the broker to accept the next available session, which takes an exclusive session lock.
3. Messages in that session are handed to the handler one at a time, in order.
4. The handler can read and write session state to remember progress.
5. When the session is empty for SessionIdleTimeout, the processor releases it and accepts another.

MaxConcurrentSessions controls how many sessions run in parallel, so throughput scales with the number of active sessions, not the number of messages.

flowchart TD
  A["Sender: SessionId=order-7"] --> B["Queue with sessions"]
  B --> C["Processor accepts session, takes lock"]
  C --> D["Handle messages in order"]
  D --> E{Session idle?}
  E -- No --> D
  E -- Yes --> F["Release lock, accept next session"]

If ActiveMessages keeps growing, work through these causes.

• No working consumer - the processor stopped, crashed or lost its credentials. Check the app logs and the OutgoingMessages metric.
• Consumer too slow - compare incoming against completed messages and raise concurrency or add instances.
• Session locked - on session entities, an orphaned or very long session blocks its messages.
• Not yet visible - scheduled or deferred messages are counted separately and will not be delivered normally.
• Lock-expiry loop - slow handlers cause redelivery, check DeliveryCount rising.
• Wrong routing - a subscription rule sends messages to a different subscription.

Use Service Bus Explorer to peek messages without locking them, and check the dead-letter and throttling metrics next.

A quick triage order is: consumers alive, throughput versus incoming rate, session or lock problems, then filter routing.

Most gains come from the client side.

• Reuse one long-lived ServiceBusClient and sender or receiver. Creating them per message is very costly.
• Batch sends with CreateMessageBatchAsync to cut network round trips.
• Raise concurrency - increase MaxConcurrentCalls and run several consumer instances.
• Use prefetch for receivers with fast handlers.
• Keep messages small and compress if needed.
• Scale the broker - add messaging units on Premium, or enable partitioning.
• Stay in the same region as the namespace to cut latency.

Measure first. Often the bottleneck is the downstream database or API, not Service Bus.

After each change, re-test with realistic message sizes and handler times. Prefetch and concurrency tuned for tiny messages often behave very differently under real load. Also avoid doing slow work such as large database writes inside the receive loop without enough concurrency.

Geo-DR is a Premium feature. You pair a primary namespace in one region with a secondary in another and expose them under one alias hostname.

Only metadata is replicated: queues, topics, subscriptions, rules and settings. Messages themselves are not copied. Applications connect to the alias, never to the namespace directly.

On a regional outage you trigger a manual failover. The alias then points at the secondary, and the pairing is broken. Messages still in the primary stay there until it recovers, so plan for that gap in your RPO. Newer geo-replication options that also replicate data exist on Premium, so check the current docs for availability and modes.

flowchart LR
  App --> Alias["Alias FQDN"]
  Alias --> P["Primary namespace"]
  P -. metadata only .-> S["Secondary namespace"]
  Alias -. after failover .-> S

Use two layers.

Client-level retries handle transient network or service errors. ServiceBusRetryOptions defaults to exponential mode, 3 retries, 0.8 s delay and a 60 s maximum delay.

Message-level retries handle business failures. Abandon the message so it is redelivered, up to MaxDeliveryCount, then it goes to the DLQ.

Never retry permanent errors, since that only wastes the delivery budget.

Add a circuit breaker around a failing dependency, so consumers pause instead of burning every message's delivery attempts during an outage. Record the attempt number in logs for easier diagnosis. Keep retry delays well below the lock duration, or renew the lock while waiting.

Throttling shows up as ServerBusyException or an HTTP 429, and the SDK retries it with back-off. If it persists, find out whether you are hitting a limit.

1. Check the ThrottledRequests metric and the CPU and memory usage of the namespace (Premium).
2. Look for bursts from too many senders or very small, unbatched sends.
3. Reduce the request rate with batching and back-off.
4. On Premium, add messaging units or enable autoscale. On Standard, consider upgrading to Premium.
5. Spread unrelated workloads across separate namespaces.

On Standard, throttling is also affected by other tenants, which is a key reason to move critical workloads to Premium.

If the cause is an unbatched burst, the fix is often client-side. A single batch send counts far less than hundreds of individual sends.

For most production workloads, Entra ID is better.

SAS still helps for third parties without an Azure identity or for time-limited delegated access. Whichever you use, grant the least privilege and consider disabling local auth once all clients use Entra ID.

Migration tip: add the Entra role assignments first, switch clients over one at a time, verify traffic in metrics, and only then disable local auth. For service-to-service calls inside Azure, managed identities remove key rotation work entirely.

Saving to your database and publishing to Service Bus are two separate systems, so a crash between them leaves data saved but no message sent, or the reverse. Service Bus transactions cannot enlist your database.

With an outbox, you write the business change and an outbox row in the same database transaction. A background relay then reads unsent rows, publishes them and marks them sent.

Set the outbox row ID as MessageId so duplicate detection drops repeats if the relay crashes mid-way. Consumers should still be idempotent.

An alternative is Change Data Capture, which publishes from the database log. It removes the relay table, but ties you to the database's features.

flowchart LR
  A[API] -->|1. one DB transaction| B[(Business table + Outbox table)]
  C[Relay] -->|2. read unsent| B
  C -->|3. publish MessageId=outbox id| D["Service Bus"]
  C -->|4. mark sent| B

They tune different things, so don't mix them up.

Prefetch cuts network latency and helps when handlers are fast. Concurrency increases processing parallelism. Start with a modest prefetch, raise concurrency to match what your dependencies can take, and watch for lock-lost errors.

Typical starting point: modest prefetch, concurrency sized to the downstream limit, then watch the lock-lost and abandoned message counts as you tune. Prefetch counts apply per receiver, so total buffered messages grow with the number of instances.

Use platform metrics for health and diagnostic logs for detail.

Send diagnostic logs such as operational and runtime audit logs to Log Analytics and query them with KQL. Set action-group alerts on the DLQ count, since nothing else tells you that messages are failing.

Use dashboards for trend views, and alerts for what needs action. A DLQ above zero, rising active messages and throttling are the three most useful alerts. Add a dashboard tile for each so the on-call engineer sees backlog and failure trends together in one view.

Service Bus has no built-in message priority, so you build it with separate paths per priority.

Publish to a topic with a Priority property. Create subscriptions with correlation filters for high, normal and low. Give the high subscription more consumers, or poll it first.

Avoid starving the low tier by guaranteeing it a minimum number of consumers. An alternative is separate queues per priority, which is simpler if there is no fan-out.

This design is simple to monitor too: each priority has its own backlog metric, so you can alert on high-priority latency separately. Alert separately when the high-priority backlog age exceeds your target, since that is the SLA that matters.

flowchart LR
  P[Publisher] --> T[Topic]
  T -->|Priority=high| H["High sub: many consumers"]
  T -->|Priority=normal| N["Normal sub"]
  T -->|Priority=low| L["Low sub: few consumers"]

A queue hands messages out in order, but two consumers working in parallel can finish them in any order. Retries make it worse, because an abandoned message is redelivered after later ones may already be done.

If order matters you have three options:

1. Sessions - one receiver owns a session, so its messages are handled sequentially. This is the standard answer.
2. Single consumer with MaxConcurrentCalls = 1, which limits scale.
3. Sequence checks in the consumer, using a business version number to discard or park out-of-order messages.

On partitioned entities, ordering is only guaranteed within a partition, so use a stable PartitionKey or SessionId.

In practice, many systems accept loose ordering and rely on idempotent handlers plus version numbers, using sessions only for the streams where strict order truly matters.

KEDA watches the backlog and scales your deployment, even down to zero. The azure-servicebus scaler reads the queue or subscription message count.

Set a graceful shutdown period longer than your handler time, so scale-down does not cut messages mid-processing and push them back through lock expiry. Also test scale-from-zero latency, since the first message waits for a pod to start.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: orders-worker
spec:
  scaleTargetRef:
    name: orders-worker
  minReplicaCount: 0
  maxReplicaCount: 20
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: orders
      messageCount: "50"
    authenticationRef:
      name: sb-auth

Authenticate with workload identity through a TriggerAuthentication. Set messageCount to the backlog one replica can handle, and cap replicas to what downstream systems tolerate. With sessions, replicas beyond the number of active sessions sit idle.