Service Bus Queues

A Queue in Azure Service Bus is a temporary holding area for messages. Senders place messages into the queue, and receivers pick them up one at a time. This one-to-one delivery model is called point-to-point messaging. The queue ensures that every message reaches exactly one receiver, even if the receiver is offline when the message arrives.

How a Queue Works

[Sender App]
     |
     | 1. sends message
     v
[  Q U E U E  ]
 [msg1][msg2][msg3]
     |
     | 2. receiver picks up one message at a time
     v
[Receiver App]
     |
     | 3. processes message and sends "Complete"
     v
[Message deleted from queue]

Queue Properties Explained

Each queue has a set of configurable properties. Understanding these properties prevents common issues like message loss, processing failures, and capacity overflows.

Property	What It Controls	Default Value
Name	Unique name of the queue within the namespace	—
Max Queue Size	Total storage capacity of the queue	1 GB
Message TTL (Time-To-Live)	How long a message waits before it expires	14 days
Lock Duration	How long a receiver holds a message lock before it auto-releases	60 seconds
Max Delivery Count	How many times a failed message retries before going to Dead Letter Queue	10
Dead-Lettering on Expiry	Move expired messages to Dead Letter Queue instead of deleting	Disabled
Duplicate Detection	Ignore duplicate messages based on MessageId	Disabled
Sessions	Enable ordered, grouped message delivery	Disabled
Partitioning	Distribute queue data across multiple message brokers for scale	Disabled

Create a Queue — Azure Portal

Open the Service Bus Namespace in the Azure Portal
Click Queues in the left menu
Click + Queue
Enter the queue name: orders
Configure properties (Max Size, TTL, Lock Duration)
Click Create

Create a Queue — Azure CLI

az servicebus queue create \
  --resource-group rg-messaging-prod \
  --namespace-name myshopns \
  --name orders \
  --max-size 1024 \
  --default-message-time-to-live P14D \
  --lock-duration PT1M \
  --max-delivery-count 10

CLI Parameter Reference

CLI Parameter	Meaning	Example
--max-size	Maximum queue size in MB	1024 = 1 GB
--default-message-time-to-live	ISO 8601 duration for message TTL	P14D = 14 days, PT1H = 1 hour
--lock-duration	ISO 8601 duration for lock timeout	PT1M = 1 minute, PT5M = 5 minutes
--max-delivery-count	Maximum retries before dead-lettering	10

Queue Lifecycle — Message States

A message passes through several states as it moves through the queue.

Message Arrives --> [ Active ]
                       |
          Receiver reads it --> [ Locked ]
                       |
             Processing succeeds --> [ Deleted ]
             Processing fails --> [ Active ] (retry)
             Max retries exceeded --> [ Dead Letter Queue ]
             TTL expires --> [ Dead Letter Queue or Deleted ]
             Receiver defers it --> [ Deferred ]

Queue vs Multiple Consumers — Competing Consumers Pattern

Multiple consumer instances can connect to one queue simultaneously. Azure Service Bus delivers each message to only one consumer. This is called the Competing Consumers pattern and is a standard way to scale message processing.

                       |--> [Consumer Instance 1] processes msg1
[  Q U E U E  ] ------|--> [Consumer Instance 2] processes msg2
 [msg1][msg2][msg3]    |--> [Consumer Instance 3] processes msg3

Each message goes to exactly ONE consumer.

FIFO Ordering in Queues

By default, Azure Service Bus queues do not guarantee FIFO (first-in, first-out) order when multiple consumers are connected. To guarantee FIFO order, use Sessions. A session groups messages by a Session ID and assigns them all to one consumer in order.

Scenario	Order Guarantee
Single consumer reading from queue	FIFO order is maintained
Multiple consumers reading from queue	No FIFO guarantee — use Sessions
Sessions enabled with session ID	FIFO guaranteed per session

Queue Size Management

The queue fills up when messages arrive faster than consumers process them. When the queue reaches its maximum size, senders receive an error. Monitor queue size using Azure Monitor and set alerts before it fills up.

Queue Capacity: 1 GB

Messages arriving: 100 msg/sec
Messages processed: 80 msg/sec
Net growth: 20 msg/sec -- queue fills up over time!

Solution: Add more consumer instances to increase processing rate.

Partitioned Queues

A Partitioned Queue splits data across multiple message brokers internally. This increases throughput and availability. Partitioning is available in the Standard and Premium tiers.

Non-partitioned queue:
  [Sender] --> [Single Broker] --> [Receiver]

Partitioned queue:
  [Sender] --> [Broker 1 (Partition A)]
           --> [Broker 2 (Partition B)]  --> [Receivers]
           --> [Broker 3 (Partition C)]

Partitioned queues do not guarantee strict ordering across partitions. If ordering is critical, avoid partitioning or use sessions within a single partition.

Queue Naming Best Practices

Best Practice	Example
Use lowercase and hyphens	order-processing, payment-events
Include the environment in the name	orders-dev, orders-prod
Use domain-based naming	inventory-updates, user-registrations
Avoid generic names	Avoid: queue1, testqueue, myqueue

List All Queues in a Namespace

az servicebus queue list \
  --resource-group rg-messaging-prod \
  --namespace-name myshopns \
  --output table

Delete a Queue

az servicebus queue delete \
  --resource-group rg-messaging-prod \
  --namespace-name myshopns \
  --name orders

Summary

Azure Service Bus queues provide a reliable, durable, point-to-point messaging channel. Messages wait safely in the queue until a consumer is ready. Properties like TTL, lock duration, max delivery count, and dead-lettering control how messages behave when things go wrong. The competing consumers pattern scales processing by adding more consumer instances. Sessions add FIFO ordering when strict sequence matters.

Previous lessons

Back to courses

Next lessons