Medium15 minDistributed Systems
UpdatedAug 6, 2026
Edit

Service Bus: Queue or Topic?

Question Variations

  • "When should you use a queue rather than a topic subscription?"
  • "How does peek-lock delivery lead to duplicate processing?"
  • "What belongs in a dead-letter queue recovery process?"
  • "How do Service Bus sessions preserve order?"

Why This Is Asked

An order event must trigger shipping, analytics, and customer notifications, while a PDF-rendering task must run once. This tests whether a candidate can select queues or topics and design reliable receive and recovery behavior.

Key Concepts

  • Queues and topics: Queues distribute one message to one competing consumer; topics fan copies out to subscriptions.
  • Peek-lock: A consumer completes a message only after successful processing; failures permit redelivery.
  • Dead-letter queues: Poisoned or expired messages require inspection, remediation, and an explicit replay decision.
  • Sessions: A session ID can preserve ordered processing for related messages while still allowing parallel sessions.

Question Variations

  • “When should you use a queue rather than a topic subscription?”
  • “How does peek-lock delivery lead to duplicate processing?”
  • “What belongs in a dead-letter queue recovery process?”
  • “How do Service Bus sessions preserve order?”

Answers by Technology

+ Add Variant
Azure Service BusImprove this answer ✏️

Expected Answer

Use an Azure Service Bus queue for point-to-point work: competing receivers process each message once from that queue. Use a topic with subscriptions for fan-out: each subscription receives its own copy and can apply filters. The sender is decoupled from receiver availability because Service Bus durably stores messages. Choose entities by business delivery requirements rather than by the number of current consumers; a topic lets new independent reactions be added without changing the producer.

For reliable work, use peek-lock receive mode. Process the message, make the business effect durable and idempotent, then complete it. If the process fails before completion or the lock expires, Service Bus can redeliver it, so duplicate detection belongs in the application. Set a sensible lock duration, renew it only for legitimate long-running work, and use max-delivery counts plus a dead-letter queue for messages that repeatedly fail. Inspect, classify, repair, and explicitly resubmit dead-letter messages; a DLQ is not an automatic recovery system. Sessions can group related messages by session ID and preserve ordered processing within that session.

Why It Matters

Receive-and-delete can lose work on a consumer crash, while unmonitored dead-letter queues hide production failures. Correct settlement and recovery practices make asynchronous workflows dependable.

Example Code

const receiver = client.createReceiver("orders", { receiveMode: "peekLock" });
const messages = await receiver.receiveMessages(10);
for (const message of messages) {
  try {
    await applyIdempotently(message.messageId!, message.body);
    await receiver.completeMessage(message);
  } catch (error) {
    await receiver.abandonMessage(message);
  }
}

Common Mistakes

  • Using receive-and-delete for important work: A crash after receipt loses the message with no opportunity for redelivery.
  • Treating the dead-letter queue as a trash bin: Uninspected poison messages accumulate and leave business workflows incomplete.

Follow-up Questions

  • Why can peek-lock still produce duplicates? (Answer: Processing may succeed but completion can fail or the lock can expire before settlement.)
  • When use a topic? (Answer: When multiple independent subscriptions each need a copy of an event.)

Related Questions

References