Azure Service Bus Interview Questions: Sessions, Duplicate Detection, and Dead-Letter Recovery

Azure Service Bus questions become clear when you separate four mechanisms: broker-side duplicate detection at send time, session ordering at receive time, PeekLock settlement, and application-level idempotency around side effects. A dead-letter queue preserves messages for inspection; it does not automatically repair or replay them.

The preparation method in this guide is deliberately practical: build a small model, change one condition at a time, predict the result, and compare the prediction with a recorded check. The eight-message payment timeline is an original local model based on Microsoft Learn. No Azure namespace, paid resource, or real queue was created.

Start with Design distributed message queue service after the worked scenario.

Use Microsoft Service Bus Semantics Precisely

Official fact: Microsoft documents duplicate detection as tracking application-controlled MessageId values during a configured history window. Matching IDs sent within the window are accepted by the service but dropped as duplicates.

Official fact: Message sessions provide exclusive session locks and ordered handling for messages with the same SessionId. They do not promise one total order across different sessions.

Official fact: Under PeekLock, a receiver settles a locked message with operations such as Complete, Abandon, Defer, or DeadLetter. If the lock expires or settlement is lost, delivery can repeat; the application must make the business effect idempotent.

Candidate-report boundary: No candidate account is needed to establish the technical behavior in this guide. Any process description should come from the reader’s invitation.

Editorial inference: Interviewers can test whether a candidate knows where each guarantee stops by presenting the same MessageId, different SessionIds, a lost Complete, and a DLQ replay in one timeline. That is why the rest of this article emphasizes a reusable reasoning method instead of a supposedly fixed question list.

Before practicing, write down the runtime, product or service version, input contract, and allowed tools. Version details are part of the answer, not administrative trivia. If the invitation is company-specific, ask the recruiter only for format details that affect preparation: language, editor, expected deliverable, time box, and tool rules. Do not ask for the prompt.

Separate Broker Guarantees from Consumer Guarantees

MessageId window

Duplicate detection compares MessageId within the configured entity window. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: A resend inside the window is identified before delivery.

Session scope

Ordering and exclusive locks apply inside a SessionId. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: Cross-session order is not claimed.

PeekLock settlement

Processing and settlement are separate; a lost lock or Complete can cause redelivery. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: Business writes use an idempotency key.

Delivery count

Repeated abandon or lock loss advances delivery toward MaxDeliveryCount. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: The DLQ reason is tied to observed delivery history.

DLQ recovery

Inspect reason, repair the cause, and deliberately resend or process the dead-lettered message. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: Recovery avoids repeating an already-applied side effect.

The five ideas belong in one explanation. Begin with the request or event, identify the controlling state, follow the transition, and finish at the observable output. Avoid reciting definitions separately. A good interviewer can then change one assumption and see whether your model still holds.

Work Through Eight Payment Messages

Use messages M1 through M8. M1 and M2 share MessageId pay-7; M3 uses another ID in session A; M4 is in session B; M5 completes its payment but loses the Complete response; M6 exceeds deliveries; M7 is manually dead-lettered for invalid schema; M8 is a repaired replay with a new transport ID but the same business idempotency key.

t0  M1 id=pay-7 session=A -> broker accepts
t1  M2 id=pay-7 session=A -> duplicate window drops
t2  M3 id=pay-8 session=A -> waits behind M1
t3  M4 id=pay-9 session=B -> may process concurrently
t4  M5 business key=order-10 -> charge succeeds, Complete response lost
t5  M5 redelivered -> consumer idempotency prevents second charge
t6  M6 delivery count exceeds limit -> DLQ
t7  M8 repaired replay -> verify side effect before resend

Use this trace rather than jumping straight to a fix:

1. Send — Record MessageId, SessionId, partitioning inputs, and duplicate window.
2. Acquire — Name the entity or session lock and its expiry.
3. Process — Separate database or payment effects from broker settlement.
4. Settle — Record Complete, Abandon, Defer, DeadLetter, or lock loss.
5. Inspect DLQ — Capture dead-letter reason, delivery count, and original identifiers.
6. Replay safely — Repair the cause, preserve business idempotency, and monitor the new delivery.

The local companion check records these predictions. It passed 6 of 6 assertions. Test boundary: A local eight-event state model checked broker dedupe, session order, lock-loss redelivery, idempotent side effects, and DLQ recovery decisions. It did not invoke Azure Service Bus. No credentialed vendor environment was used, so the result verifies the model and arithmetic only. It does not prove hosted behavior, quotas, latency, or account-specific configuration.

Change One Condition at a Time

The fastest way to expose shallow understanding is to change several variables at once. Instead, use paired cases. Keep the request and surrounding state fixed, then alter only the version, identifier, policy, timeout, watermark, or failure point. Say what changed in the governing rule before giving the new output.

Changed condition	Prediction	Evidence to inspect	Best response
Same MessageId in window	Second send is dropped by duplicate detection	Broker send history	Keep stable transport ID for retries
Different SessionId	May process concurrently	Session lock owners	Do not claim global order
Complete response lost	Message can redeliver	Lock and settlement logs	Check business key before effect
Max deliveries exceeded	Message moves to DLQ	Delivery count and reason	Repair cause before replay
DLQ replay with new MessageId	Broker sees a new send	New transport ID and old business key	Keep application idempotency

For every row, separate an observed fact from an assumption. Logs, documented fields, an execution history, and a reproducible test are evidence. A plausible architecture guess is still a guess. If a required field is missing, ask for that field and explain how each possible value would alter the diagnosis.

Common Interview Traps

• Calling duplicate detection exactly once: It is windowed broker dedupe, not an end-to-end business guarantee. A stronger answer states what would happen, why, and how to verify it.
• Claiming global ordering: Sessions order only their own sequence. A stronger answer states what would happen, why, and how to verify it.
• Confusing deferral with a receive mode: Deferral is a settlement operation under the receive model. A stronger answer states what would happen, why, and how to verify it.
• Treating Complete and side effect as atomic: They cross systems and can split. A stronger answer states what would happen, why, and how to verify it.
• Assuming DLQ auto-replays: Operators or applications must inspect and recover messages. A stronger answer states what would happen, why, and how to verify it.

Another trap is proposing a large redesign before proving the failure. Prefer the smallest safe correction that restores the contract, then describe a follow-up improvement if the design still creates operational risk. This shows scope control and leaves room for the interviewer to add a requirement.

Explain the Result as an Engineering Decision

Use a four-part answer: decision, rule, evidence, consequence. For example: “I predict this path will fail. The controlling rule is X. The event history shows Y. Therefore I would change Z and add this regression check.” The exact nouns vary by topic; the structure stays useful.

When there is a trade-off, name both sides concretely. A longer duplicate window reduces repeated sends but consumes more tracking capacity and can reduce throughput; sessions preserve per-key order but constrain concurrency for hot keys. Choose a default for the stated workload, and say what measurement or requirement would make you choose differently. “It depends” becomes useful only after you name the dependency.

For troubleshooting questions, end with a safe next action. Preserve evidence before changing state. Prefer a reversible mitigation, define the success signal, and state what would trigger rollback or escalation. For implementation questions, end with a boundary test and an invariant. For design questions, end with capacity and failure assumptions.

Practice Questions and Follow-Ups

Work through these prompts aloud:

1. Explain the normal path without using framework vocabulary. What enters, what state changes, and what leaves?
2. Which single field or timestamp would you inspect first after the reported failure, and why?
3. What happens if the same operation is retried after the external side effect succeeds?
4. Which answer changes across the versions or modes named in the title?
5. What is the smallest regression test that prevents this failure from returning?
6. How would you explain the same incident to an engineer and to a non-specialist stakeholder?

A complete answer should survive one follow-up. After your first response, add a constraint such as a lower resource limit, a late event, a cross-account boundary, a process crash, or a changing requirement. Update only the affected part of your model and keep prior invariants visible.

Verified question	Focus	Practice output
Design distributed message queue service	Broker guarantees	Write a prediction, evidence path, and decision
Explain Kafka and Message-Queue Delivery Semantics	Delivery contracts	Write a prediction, evidence path, and decision
Implement a Concurrent Payment Queue with Visibility Timeouts	Locks and redelivery	Write a prediction, evidence path, and decision
Prevent Duplicate Payments Under High Load	Business idempotency	Write a prediction, evidence path, and decision
Troubleshoot a production incident end-to-end	Evidence and recovery	Write a prediction, evidence path, and decision

A Focused Preparation Routine

On the first pass, spend 25 minutes reconstructing the governing rules from official documentation and write three paired predictions. On the second, spend 35 minutes on the original scenario, including one failure and one recovery. On the third, explain the result aloud in ten minutes, then answer two changing-requirement follow-ups.

Review the recording or notes for four signals: did you state the version; did you distinguish fact from inference; did you prove the failure with the smallest useful trace; and did your recommended change preserve the original contract? Count evidence-backed decisions, not the number of terms you mentioned.

Finish by preparing two questions for the interviewer about the real team’s constraints. Ask about workload shape, failure ownership, testing environments, or observability. Those questions connect the exercise to engineering work without pretending that public documentation reveals a private interview rubric.

Trace the message from send through settlement and recovery. When you can name the identifier, lock, side effect, and evidence at each step, the interview answer becomes both precise and operational.

Sources and Further Reading

• Azure Service Bus message locks and settlement — official receive and settlement behavior
• Azure Service Bus duplicate detection — official MessageId window behavior
• Azure Service Bus sessions — official session locking and order
• Azure Service Bus dead-letter queues — official DLQ reasons and handling