Service Bus Sessions and Duplicate Detection

Service Bus sessions enable ordered, grouped processing of messages. A session is a logical grouping of messages that share a SessionId property. All messages with the same SessionId are guaranteed to be delivered in order (FIFO) and are locked to a single consumer until that consumer completes or abandons them. This is crucial for scenarios where message order matters, such as processing bank transactions or IoT device telemetry.

When a queue or subscription has RequiresSession set to true, messages must have a SessionId. The broker maintains a session state that persists across messages. A consumer must accept a session by calling AcceptMessageSessionAsync() (or using the SessionProcessor in the SDK). The consumer then receives all messages for that session exclusively. The session lock is renewed automatically by the SDK (default lock duration is 1 minute, configurable up to 5 minutes). If the consumer fails, the session becomes available to other consumers after the lock expires.

Duplicate detection ensures that messages with the same MessageId are not delivered more than once within a specified time window. The broker maintains a history of recently processed MessageIds. If a new message arrives with a MessageId that matches one in the history, it is silently discarded (accepted but not enqueued).

When a message is sent, the broker checks if its MessageId exists in a duplicate detection history for that queue/topic. The history is an in-memory cache that persists for a configurable duplicate detection history time window (default 10 minutes, max 7 days). If found, the message is not enqueued, but the send operation returns success (to avoid sender confusion). If not found, the message is enqueued and its MessageId is added to the history.

Using Azure CLI:

# Create a queue with sessions and duplicate detection
az servicebus queue create --resource-group myRG --namespace-name myNS \
  --name myQueue --requires-session true --requires-duplicate-detection true \
  --duplicate-detection-history-time-window PT10M

Using C# SDK:

// Send message with session and duplicate detection
var message = new ServiceBusMessage("Hello")
{
    SessionId = "session1",
    MessageId = Guid.NewGuid().ToString()
};
await sender.SendMessageAsync(message);

// Receive messages from a session
var sessionReceiver = await client.AcceptSessionAsync("session1");
var message = await sessionReceiver.ReceiveMessageAsync();

An online retailer uses Service Bus queues to process orders. Each order generates multiple messages: payment, inventory, shipping. Using sessions with the OrderId as SessionId ensures all messages for an order are processed by the same consumer in order. Duplicate detection prevents double-charging if the payment gateway retries. The queue is configured with RequiresSession=true and RequiresDuplicateDetection=true. The duplicate detection time window is set to 1 hour to cover retry windows. The consumer uses a SessionProcessor with MaxConcurrentSessions=5 to handle multiple orders simultaneously. Misconfiguration: if the time window is too short (e.g., 1 minute), a retry after 2 minutes could cause duplicate payment.

A fleet management company collects telemetry from thousands of vehicles. Each vehicle has a unique device ID. Messages from a vehicle must be processed in order to track location history. Sessions with DeviceId as SessionId guarantee ordering. Duplicate detection is enabled with a 5-minute window to handle intermittent network retries. The consumer scales out by accepting different sessions. Performance consideration: session state stores the last known location to enable incremental updates. If state grows too large (over 256 KB), it can cause throttling.

A bank processes fund transfers using Service Bus topics. Each transfer generates a debit and credit message. Sessions with TransactionId ensure atomic processing: the consumer completes both messages or dead-letters the session. Duplicate detection prevents duplicate debits. The duplicate detection window is set to 7 days (maximum) to cover settlement periods. The consumer must handle session lock renewal for long-running transactions. Common issue: if the consumer crashes mid-session, the session becomes available to another consumer, but the session state (e.g., 'debit done') must be used to avoid reprocessing the debit.