Queue & Table Storage
Azure Queue Storage decouples application components via asynchronous messaging. Azure Table Storage is a simple, cheap NoSQL key-value store — both live within a standard Storage Account.
Part 1: Queue Storage
Simple Explanation
A Queue is like a physical ticket dispenser: a producer drops a ticket (message), a worker picks it up and processes it — independently, at their own pace. The queue absorbs bursts without overwhelming the processor.
When to Use Queue Storage
- Decoupling a web frontend from a slow background process (image processing, email sending).
- Handling traffic bursts — messages wait in the queue until workers catch up.
- Triggering Azure Functions on new messages.
- Simple FIFO processing pipelines without complex routing.
Queue Storage: simple, cheap, up to 64 KB per message, 500 TB queue size, no ordering guarantee. Azure Service Bus: enterprise messaging with message ordering, dead-letter queues, sessions, and topics/subscriptions. Use Queue Storage for simple decoupling; Service Bus for enterprise workflows.
Queue Key Concepts
- Visibility timeout: When a consumer dequeues a message, it becomes invisible to other consumers for a configurable period. If not deleted in time, it reappears for retry.
- Message TTL: Maximum time a message lives in the queue before expiry (default 7 days, max 7 days for Storage Queues).
- Poison messages: Messages that fail repeatedly — move them to a dead-letter queue manually or via logic in your consumer.
Part 2: Table Storage
Simple Explanation
Table Storage is a NoSQL spreadsheet: rows are indexed by a Partition Key + Row Key pair, and each row can have different columns. No joins, no foreign keys — just fast key-value lookups.
When to Use Table Storage
- Low-cost NoSQL lookups that don't need complex queries or relationships.
- Storing session data, user preferences, IoT telemetry, or audit logs.
- When Cosmos DB's features are overkill and cost is a priority.
| Table Storage | Cosmos DB Table API | |
|---|---|---|
| Cost | Very low (cents/GB/month) | Higher (RU-based) |
| Latency | Low but variable | Guaranteed < 10 ms |
| Global distribution | Via GRS (no multi-write) | Multi-region writes |
| Best for | Simple cheap storage | Global apps, SLA-critical |
Commands
# Create a queue
az storage queue create \
--account-name mystorageacct \
--name orders-queue
# Send a message
az storage message put \
--account-name mystorageacct \
--queue-name orders-queue \
--content '{"orderId":"123","item":"widget","qty":5}'
# Peek (don't remove message)
az storage message peek \
--account-name mystorageacct \
--queue-name orders-queue
# Dequeue (message becomes invisible for 30s)
az storage message get \
--account-name mystorageacct \
--queue-name orders-queue \
--visibility-timeout 30
# Delete a message (after processing)
az storage message delete \
--account-name mystorageacct \
--queue-name orders-queue \
--id <message-id> \
--pop-receipt <pop-receipt># Create a table az storage table create \ --account-name mystorageacct \ --name UserSessions # Insert an entity az storage entity insert \ --account-name mystorageacct \ --table-name UserSessions \ --entity PartitionKey=US RowKey=user123 SessionToken=abc123 CreatedAt=2024-01-15 # Query an entity az storage entity show \ --account-name mystorageacct \ --table-name UserSessions \ --partition-key US \ --row-key user123
Hands-on
- Create a queue called
job-queueand send 5 messages with sample JSON payloads. - Dequeue messages one at a time; observe the visibility timeout in action.
- Create a Table and insert 3 entities with different partition keys.
- Query by partition key and observe performance with large vs small partitions.
- Write an Azure Function with a Storage Queue trigger that logs each message.
Debugging Scenario
Issue: Messages are accumulating in the queue and not being processed.
- Check if the consumer (Function or worker) is running: look at App Insights or VM process list.
- Check if messages are poisoned — if a consumer crashes during processing, the visibility timeout expires and the message reappears. After too many reappearances it becomes "poison" and blocks the queue.
- Set a dequeue count threshold in your consumer and move high-dequeue-count messages to a dead-letter container for investigation.
Interview Questions
Beginner
Decoupling: the producer does not need to wait for the worker to finish. If the worker is down or slow, messages buffer in the queue without losing data.
When a consumer dequeues a message, it becomes hidden for a set period. If the consumer doesn't delete it within that time (e.g., crashes), the message reappears for another consumer to retry.
Scenario-based
API accepts the upload, stores the image in Blob, drops a message in a Queue with the blob path, and returns 202 Accepted immediately. A pool of workers (or Functions) process the queue asynchronously.
Summary
Queue Storage enables resilient async processing between loosely coupled components. Table Storage provides a very low-cost NoSQL option for simple key-value data. Both are part of a standard Storage Account. Use Service Bus when you need advanced messaging guarantees beyond what Queue Storage provides.