Message ordering and sessions in Azure - Step-by-Step Execution

Process Flow - Message ordering and sessions

Send messages with SessionId

↓

Messages arrive at queue/topic

↓

Service groups messages by SessionId

↓

Receiver accepts a session

↓

Messages delivered in order within session

↓

Session state can be stored and updated

↓

Receiver completes session processing

↓

End

Messages are sent with a session ID. The service groups messages by this ID. Receivers accept sessions and get messages in order. Session state can be stored and updated during processing.

Execution Sample

Azure

Send message1 with SessionId='A'
Send message2 with SessionId='A'
Send message3 with SessionId='B'
Receiver accepts SessionId='A'
Receiver processes messages in order

This example shows sending messages with session IDs and a receiver processing messages in order for a specific session.

Process Table

Step	Action	SessionId	Message Order	Receiver State	Output
1	Send message1	A	1	None	Message1 queued
2	Send message2	A	2	None	Message2 queued
3	Send message3	B	1	None	Message3 queued
4	Receiver accepts session	A	-	Session A accepted	Ready to receive messages
5	Receiver receives message1	A	1	Processing message1	Message1 delivered
6	Receiver receives message2	A	2	Processing message2	Message2 delivered
7	Receiver completes session	A	-	Session A closed	Session processing done
8	Receiver tries to receive from session B	B	-	Session B not accepted	No messages delivered

💡 Receiver stops after completing session A; messages in session B remain until accepted.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	After Step 8
Queue Messages	Empty	Message1 (A, order 1)	Message1, Message2 (A, order 2)	Message1, Message2 (A), Message3 (B, order 1)	Same	Message2 (A), Message3 (B)	Message3 (B)	Message3 (B)	Message3 (B)
Receiver Session	None	None	None	None	Session A accepted	Session A processing message1	Session A processing message2	Session A closed	Session A closed

Key Moments - 3 Insights

Why does the receiver only get messages from one session at a time?

Because the receiver accepts a specific session (see Step 4 in execution_table), it processes messages only from that session to maintain order.

What happens to messages in other sessions while one session is being processed?

Messages in other sessions remain in the queue until their session is accepted by a receiver (see Step 8). They are not delivered out of order.

How is message order guaranteed within a session?

Messages with the same SessionId are delivered in the order they were sent (see Steps 5 and 6), ensuring ordered processing.

Visual Quiz - 3 Questions

Look at the execution_table at Step 5. What message does the receiver process?

A Message2 with SessionId 'A'

B Message1 with SessionId 'A'

C Message3 with SessionId 'B'

D No message

💡 Hint

Check the 'Action' and 'Output' columns at Step 5 in execution_table.

At which step does the receiver close the session?

A Step 7

B Step 8

C Step 6

D Step 4

💡 Hint

Look for 'Session closed' in the 'Receiver State' column in execution_table.

If the receiver accepts session 'B' at Step 4 instead of 'A', what changes in the execution_table?

A Messages from session 'A' are delivered first

B No messages are delivered

C Messages from session 'B' are delivered in order

D Messages from both sessions are delivered simultaneously

💡 Hint

Refer to how session acceptance controls message delivery order in execution_table Steps 4-6.

Concept Snapshot

Message ordering and sessions in Azure Service Bus:
- Messages sent with SessionId are grouped.
- Receiver accepts one session at a time.
- Messages within a session are delivered in order.
- Session state can be stored and updated.
- Other sessions wait until accepted.

Full Transcript

In Azure Service Bus, messages can be sent with a SessionId to group related messages. The service groups messages by this SessionId. A receiver accepts a session and processes messages from that session in the order they were sent. This ensures message ordering within the session. The receiver can store and update session state during processing. Messages from other sessions remain queued until their session is accepted. This process guarantees ordered and grouped message processing.

Practice

1. What is the main purpose of using sessions in Azure Service Bus messaging?

easy

A. To group related messages and keep their order

B. To encrypt messages for security

C. To increase message size limits

D. To automatically retry failed messages

Solution

1. Step 1: Understand session concept in messaging

   Sessions are used to group related messages so they can be processed in order.

2. Step 2: Identify the purpose of sessions

   Sessions ensure messages with the same session ID are received and processed sequentially.

3. Final Answer:

   To group related messages and keep their order -> Option A

4. Quick Check:

   Sessions = Group messages + order [OK]

Hint: Sessions keep related messages ordered by session ID [OK]

Common Mistakes:

• Thinking sessions encrypt messages
• Assuming sessions increase message size
• Confusing sessions with retry policies

2. Which property must be set on a message to assign it to a session in Azure Service Bus?

easy

A. message_id

B. correlation_id

C. session_id

D. partition_key

Solution

1. Step 1: Identify session assignment property

   The property used to assign messages to sessions is session_id.

2. Step 2: Differentiate from other properties

   message_id identifies messages uniquely, correlation_id links related messages but not for sessions, partition_key is for partitioning.

3. Final Answer:

   session_id -> Option C

4. Quick Check:

   Assign session = session_id property [OK]

Hint: Use session_id to assign messages to sessions [OK]

Common Mistakes:

• Using message_id instead of session_id
• Confusing correlation_id with session_id
• Using partition_key for session assignment

3. Given the following code snippet receiving messages by session, what will be the order of processing?

var receiver = client.AcceptSessionAsync("order123");
var message1 = await receiver.ReceiveMessageAsync();
var message2 = await receiver.ReceiveMessageAsync();

Assuming messages with session_id "order123" were sent in order: M1, M2.

medium

A. M1 processed before M2

B. M1 and M2 processed in any random order

C. Only M2 will be processed

D. M2 processed before M1

Solution

1. Step 1: Understand session receiver behavior

   Accepting a session locks it and receives messages in the order they were sent for that session.

2. Step 2: Analyze message receiving calls

   The first call receives the first message (M1), the second call receives the next message (M2), preserving order.

3. Final Answer:

   M1 processed before M2 -> Option A

4. Quick Check:

   Session receiver = ordered messages [OK]

Hint: Session receiver processes messages in sent order [OK]

Common Mistakes:

• Assuming messages arrive out of order
• Thinking only last message is received
• Confusing session with non-session receivers

4. You have a session-enabled queue but your receiver code throws an error when calling AcceptSessionAsync(). What is the most likely cause?

medium

A. The session_id property is missing on messages

B. The message size exceeds the limit

C. The client connection string is invalid

D. The queue is not session-enabled

Solution

1. Step 1: Check queue session configuration

   AcceptSessionAsync requires the queue to be session-enabled; otherwise, it throws an error.

2. Step 2: Differentiate from other causes

   Missing session_id causes messages to be non-sessioned but does not cause AcceptSessionAsync to fail; invalid connection or message size cause different errors.

3. Final Answer:

   The queue is not session-enabled -> Option D

4. Quick Check:

   AcceptSessionAsync error = queue not session-enabled [OK]

Hint: AcceptSessionAsync needs session-enabled queue [OK]

Common Mistakes:

• Assuming missing session_id causes AcceptSessionAsync error
• Blaming connection string without checking queue settings
• Confusing message size errors with session errors

5. You need to process orders in the exact order they were placed, but orders come from multiple customers simultaneously. How should you design your Azure Service Bus solution to ensure correct ordering per customer?

hard

A. Use multiple queues, one per customer, without sessions

B. Use a single session-enabled queue and assign each customer's messages a unique session_id

C. Use a single queue without sessions and process messages as they arrive

D. Use topics and subscriptions without sessions

Solution

1. Step 1: Understand ordering per customer requirement

   Ordering must be maintained per customer, but customers send messages concurrently.

2. Step 2: Choose session-enabled queue with unique session_id per customer

   Assigning each customer's messages a unique session_id groups their messages, preserving order within that session.

3. Step 3: Evaluate other options

   Single queue without sessions loses order; multiple queues add complexity; topics/subscriptions don't guarantee order per customer.

4. Final Answer:

   Use a single session-enabled queue and assign each customer's messages a unique session_id -> Option B

5. Quick Check:

   Session-enabled queue + unique session_id = per-customer order [OK]

Hint: Use session_id per customer in session-enabled queue [OK]

Common Mistakes:

• Ignoring sessions and losing order
• Using multiple queues unnecessarily
• Relying on topics without ordering guarantees