Azure Queue Storage

What Are Message Queues?

Without a queue, if Component A needs to call Component B, it calls it directly. Problems with this:

• If B is down, A fails too
• If B is slow, A waits and slows down
• If traffic spikes, both A and B get overwhelmed

With a queue in between, A drops a message into the queue and continues. B reads from the queue at its own pace. A and B are now decoupled — B can be down, slow, or restarting without affecting A at all.

How Azure Queue Storage Works

1. A producer (your application) sends a message to the queue
2. The message sits in the queue until a consumer picks it up
3. A consumer reads the message — it becomes invisible to other consumers for a configurable visibility timeout
4. If the consumer processes it successfully, it deletes the message from the queue
5. If the consumer crashes before deleting, the message becomes visible again after the visibility timeout — another consumer can pick it up

Key Concepts

Message Size

Each message can be up to 64 KB in size. For larger payloads, store the data in Blob Storage and put a reference (URL) in the queue message.

Message TTL (Time to Live)

How long a message stays in the queue before being automatically deleted. Default is 7 days. Maximum is 7 days. Minimum is 1 second. Set to -1 for messages that never expire.

Visibility Timeout

When a consumer reads a message, it becomes invisible to other consumers for this duration. Default is 30 seconds. The consumer must delete the message within this time or it reappears in the queue. Set it based on how long your processing takes.

Queue Depth

Azure Queue Storage can hold up to 500 TB of messages per queue. Essentially unlimited for practical purposes.

Dequeue Count

Each message tracks how many times it has been dequeued. If a message keeps failing, its dequeue count grows. You can use this to detect poison messages (messages that always fail processing).

Working With Queues via CLI

# Create a queue
az storage queue create \
  --name myqueue \
  --account-name mystorageaccount2026 \
  --auth-mode login

# Send a message
az storage message put \
  --queue-name myqueue \
  --content "Process order #12345" \
  --account-name mystorageaccount2026 \
  --auth-mode login

# Receive (peek) a message without removing it
az storage message peek \
  --queue-name myqueue \
  --account-name mystorageaccount2026 \
  --auth-mode login

# Get a message (makes it invisible for processing)
az storage message get \
  --queue-name myqueue \
  --account-name mystorageaccount2026 \
  --auth-mode login

# Delete a message after processing (requires message ID and pop receipt)
az storage message delete \
  --queue-name myqueue \
  --id [message-id] \
  --pop-receipt [pop-receipt] \
  --account-name mystorageaccount2026 \
  --auth-mode login

# Get queue length
az storage queue metadata show \
  --name myqueue \
  --account-name mystorageaccount2026 \
  --auth-mode login

Poison Messages

A poison message is a message that cannot be successfully processed — it keeps failing, reappearing in the queue, and failing again. Without handling, it can block processing indefinitely.

Detecting Poison Messages

Check the dequeue count. If a message has been dequeued more than a threshold (e.g., 5 times), it's likely a poison message.

Handling Poison Messages

1. Read the message and check its dequeue count
2. If dequeue count exceeds threshold, move it to a dead-letter queue (a separate queue for failed messages)
3. Delete it from the main queue
4. Alert your team to investigate the dead-letter queue

Queue Storage vs Service Bus

Azure has two queuing services. Choose the right one:

Real-World Use Cases