Service Bus queues concept in Azure - Commands & Configuration

Introduction

Sometimes apps need to talk to each other without being connected at the same time. Service Bus queues help by holding messages safely until the receiving app is ready to get them.

When you want to send orders from a website to a processing system without losing any orders.

When different parts of your app run at different speeds and need a way to pass messages reliably.

When you want to make sure messages are processed one at a time in the order they were sent.

When you need to keep messages safe even if the receiving app is temporarily down.

When you want to separate sending and receiving parts of your system to make it easier to manage.

Config File - main.tf

main.tf

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "East US"
}

resource "azurerm_servicebus_namespace" "example" {
  name                = "examplesbnamespace"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  sku                 = "Standard"
}

resource "azurerm_servicebus_queue" "example" {
  name                = "examplequeue"
  namespace_name      = azurerm_servicebus_namespace.example.name
  resource_group_name = azurerm_resource_group.example.name
  max_size_in_megabytes = 1024
  enable_partitioning = true
}

This Terraform file creates an Azure resource group, a Service Bus namespace, and a queue inside that namespace.

resource_group: Holds all resources in one place.

servicebus_namespace: The container for queues and topics.

servicebus_queue: The queue where messages are stored until processed.

Partitioning helps scale the queue for better performance.

Commands

This command sets up Terraform in the current folder, downloading the Azure provider so you can create resources.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/azurerm...

- Installing hashicorp/azurerm v3.64.0...

- Installed hashicorp/azurerm v3.64.0 (signed by HashiCorp)



Terraform has been successfully initialized!

This command creates the resource group, Service Bus namespace, and queue in Azure as defined in the config file.

Terminal

terraform apply -auto-approve

Expected Output

azurerm_resource_group.example: Creating...

azurerm_resource_group.example: Creation complete after 2s

azurerm_servicebus_namespace.example: Creating...

azurerm_servicebus_namespace.example: Creation complete after 15s

azurerm_servicebus_queue.example: Creating...

azurerm_servicebus_queue.example: Creation complete after 5s



Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

→

-auto-approve - Skip manual approval to apply changes immediately

This Azure CLI command checks the details of the queue to confirm it was created and see its settings.

Terminal

az servicebus queue show --resource-group example-resources --namespace-name examplesbnamespace --name examplequeue

Expected Output

{

  "name": "examplequeue",

  "maxSizeInMegabytes": 1024,

  "enablePartitioning": true,

  "status": "Active",

  "lockDuration": "PT1M"

}

→

--resource-group - Specifies the Azure resource group name

→

--namespace-name - Specifies the Service Bus namespace

→

--name - Specifies the queue name

Key Concept

If you remember nothing else from this pattern, remember: Service Bus queues hold messages safely until the receiver is ready, helping apps talk smoothly even if they work at different times.

Common Mistakes

Trying to send messages to a queue before it is created.

The messages will fail because the queue does not exist yet.

Always create and verify the queue first before sending messages.

Not enabling partitioning on large queues.

Without partitioning, the queue can become slow or hit size limits.

Enable partitioning to allow the queue to scale and handle more messages.

Using the wrong resource group or namespace name in commands.

Commands will fail because they cannot find the queue.

Double-check resource group and namespace names before running commands.

Summary

Use Terraform to create an Azure resource group, Service Bus namespace, and queue.

Run 'terraform apply' to deploy the queue and then verify it with Azure CLI.

Service Bus queues safely store messages until the receiving app is ready to process them.

Practice

1. What is the main purpose of an Azure Service Bus queue?

easy

A. To store files and documents

B. To host websites and web applications

C. To run virtual machines

D. To store messages until a receiver processes them

Solution

1. Step 1: Understand the role of Service Bus queues

   Service Bus queues are designed to hold messages temporarily until a receiver is ready to process them.

2. Step 2: Compare with other Azure services

   Hosting websites, storing files, or running virtual machines are tasks for other Azure services, not Service Bus queues.

3. Final Answer:

   To store messages until a receiver processes them -> Option D

4. Quick Check:

   Service Bus queues store messages = C [OK]

Hint: Queues hold messages until processed by receivers [OK]

Common Mistakes:

• Confusing queues with storage accounts
• Thinking queues run applications
• Mixing queues with virtual machines

2. Which of the following is the correct way to create a Service Bus queue using Azure CLI?

easy

A. az servicebus queue create --resource-group MyGroup --namespace-name MyNamespace --name MyQueue

B. az storage queue create --resource-group MyGroup --name MyQueue

C. az vm create --resource-group MyGroup --name MyQueue

D. az webapp create --resource-group MyGroup --name MyQueue

Solution

1. Step 1: Identify the correct Azure CLI command for Service Bus queue

   The command to create a Service Bus queue uses 'az servicebus queue create' with resource group, namespace, and queue name.

2. Step 2: Eliminate other commands

   Other commands relate to storage queues, virtual machines, or web apps, which are not Service Bus queues.

3. Final Answer:

   az servicebus queue create --resource-group MyGroup --namespace-name MyNamespace --name MyQueue -> Option A

4. Quick Check:

   Service Bus queue creation uses 'az servicebus queue create' = D [OK]

Hint: Use 'az servicebus queue create' for queues [OK]

Common Mistakes:

• Using storage queue commands for Service Bus
• Confusing VM or web app commands with queues
• Omitting namespace name in command

3. Given this code snippet using Azure SDK for Python, what will be the output if the queue is empty?

from azure.servicebus import ServiceBusClient
connection_str = "Endpoint=sb://example.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=key"
queue_name = "testqueue"

with ServiceBusClient.from_connection_string(connection_str) as client:
    receiver = client.get_queue_receiver(queue_name=queue_name)
    with receiver:
        messages = receiver.receive_messages(max_message_count=1, max_wait_time=5)
        print(len(messages))

medium

A. 1

B. 0

C. None

D. Error

Solution

1. Step 1: Understand receive_messages behavior on empty queue

   If the queue is empty, receive_messages returns an empty list after waiting max_wait_time seconds.

2. Step 2: Check the printed output

   Printing the length of the messages list will print 0 because no messages were received.

3. Final Answer:

   0 -> Option B

4. Quick Check:

   Empty queue returns empty list, length = 0 [OK]

Hint: Empty queue returns empty list, length zero [OK]

Common Mistakes:

• Expecting None instead of empty list
• Assuming an error occurs on empty queue
• Thinking it returns one message by default

4. You wrote this code to receive messages from a Service Bus queue but it throws an error:

receiver = client.get_queue_receiver(queue_name="myqueue")
messages = receiver.receive_messages(max_message_count=5)
for msg in messages:
    print(msg.body)
    receiver.complete_message(msg)

What is the likely cause of the error?

medium

A. Receiver was not used as a context manager or opened before receiving messages

B. max_message_count must be 1

C. You cannot complete messages in Service Bus

D. Queue name must be 'default'

Solution

1. Step 1: Check how receiver is used

   The receiver must be opened before receiving messages, usually by using 'with' statement or calling 'receiver.open()'.

2. Step 2: Identify missing context management

   In the code, receiver is not opened or used as a context manager, causing an error when calling receive_messages.

3. Final Answer:

   Receiver was not used as a context manager or opened before receiving messages -> Option A

4. Quick Check:

   Receiver must be opened before use = B [OK]

Hint: Always open receiver with 'with' or open() before receiving [OK]

Common Mistakes:

• Not opening receiver before receiving messages
• Thinking max_message_count must be 1
• Believing message completion is not allowed

5. You want to ensure that messages that cannot be processed after multiple attempts are not lost but moved for later inspection. Which Service Bus queue feature should you use?

hard

A. Duplicate detection

B. Auto-delete on idle

C. Dead-letter queue

D. Partitioning

Solution

1. Step 1: Understand message failure handling

   Messages that fail processing multiple times should be moved to a special queue to avoid loss and allow inspection.

2. Step 2: Identify the dead-letter queue feature

   Service Bus provides a dead-letter queue for this purpose, storing messages that cannot be delivered or processed.

3. Final Answer:

   Dead-letter queue -> Option C

4. Quick Check:

   Dead-letter queue stores failed messages = A [OK]

Hint: Use dead-letter queue for failed message handling [OK]

Common Mistakes:

• Confusing dead-letter with auto-delete
• Thinking duplicate detection handles failures
• Assuming partitioning manages failed messages