Queue Storage and Azure Files

Microsoft Azure · Practical · 10 min

Queue Storage is the simplest way to decouple work; Azure Files replaces file servers and shared volumes.

Queue Storage holds large numbers of small messages (up to 64 KB each) in a storage account. The consumer pattern is:

1. Get a message: it becomes invisible for a visibility timeout (default 30 seconds). 2. Process it. 3. Delete it using the pop receipt. If the worker crashes, the message reappears after the timeout and another worker retries it.

Each message has a dequeueCount; move messages that keep failing to a "poison" queue (the Functions queue trigger does this after 5 attempts). Messages expire after a time-to-live (7 days by default). There is no ordering guarantee, no topics and no transactions; when you need those, use Service Bus.

Azure Files provides fully managed file shares over SMB (Windows, Linux, macOS) and NFS (Linux, Premium tier). Uses: lift-and-shift apps that expect a file server, shared configuration, persistent volumes for containers (Container Apps and AKS can mount shares). Standard shares run on HDD-based storage; Premium on SSD with provisioned performance. Azure File Sync caches shares on on-premises Windows servers.

Identity-based SMB access works with Active Directory or Entra Kerberos; avoid distributing the storage account key for mounts when you can.

Example

# pip install azure-storage-queue azure-identity
from azure.identity import DefaultAzureCredential
from azure.storage.queue import QueueClient

q = QueueClient("https://stordersprod01.queue.core.windows.net", "thumbnails",
                credential=DefaultAzureCredential())
q.send_message('{"blob": "photos/cat.jpg"}')

for msg in q.receive_messages(visibility_timeout=60, max_messages=10):
    try:
        print("processing", msg.content, "attempt", msg.dequeue_count)
        q.delete_message(msg)            # only after success
    except Exception:
        pass                             # reappears after 60 s for a retry

Remember

  • Receive hides a message; delete after success; crash = automatic retry
  • Watch dequeueCount and park poison messages
  • No ordering or pub/sub: that is Service Bus territory
  • Azure Files = managed SMB/NFS shares, mountable by VMs and containers

Watch out for

  • Deleting the message as soon as it is received, so a crash loses the work.

Check yourself

  1. A worker receives a queue message and then crashes before deleting it. What happens?

Sign in to answer, see the explanations, and get this lesson back as a quick review later.

Official docs: learn.microsoft.com/en-us/azure/storage/queues/storage-queues-introduction