Question

Difficulty: HardImplement Azure Queue Storage Solutions

You are developing an Azure-hosted application that processes large batch PDF generation requests. Each request contains user preferences and a raw list of data records to include. The size of the request payload ranges from 10 KB to 500 KB. You plan to use Azure Queue Storage to process these requests asynchronously using a background worker. You need to design the solution to handle the request payloads while minimizing costs and ensuring reliability. Which approach should you implement to handle the request payloads?

  1. A
    Send the payload directly to the queue using QueueClient.SendMessageAsync. Configure the storage account to use the Premium tier (SSD-based) to increase the queue's maximum message size to 1 MB.
  2. B
    Create a system-assigned managed identity for the application, assign the Storage Queue Data Message Sender role, and use it to authenticate the client. The Azure SDK automatically compresses and splits messages larger than 64 KB into metadata attributes when managed identities are used.
  3. Upload the request payload to an Azure Blob Storage container, write the URI of the blob as the message content to the Azure Queue Storage queue, and have the worker retrieve the payload from Blob Storage and delete the blob after processing.Answer
  4. D
    Generate a service-level Shared Access Signature (SAS) token with write permissions for the queue, and include the SAS token in the queue message properties to authorize payload sizes up to 256 KB.

Answer

Upload the request payload to an Azure Blob Storage container, write the URI of the blob as the message content to the Azure Queue Storage queue, and have the worker retrieve the payload from Blob Storage and delete the blob after processing.
The correct option is the one that uploads the payload to Azure Blob Storage and writes the blob's URI to the queue. Azure Queue Storage has a hard message size limit of 64 KB. For payloads exceeding this limit (such as requests ranging from 10 KB to 500 KB), the industry-standard pattern is to store the actual data in Blob Storage and pass a reference (such as the blob URI) in the queue message. The processing worker can then read the reference, retrieve the blob content, process it, and delete the blob.

Step-by-Step Solution

1
Analyze the message payload size requirements.
The payload size ranges from 10 KB to 500 KB, which can exceed the maximum message size limit of Azure Queue Storage.
Azure Queue Storage has a hard message size limit of 64 KB per message.
2
Determine the appropriate Azure service for storing payloads larger than 64 KB.
Azure Blob Storage is selected to store the large request payloads.
Blob Storage is designed to store unstructured data of virtually any size cost-effectively.
3
Design the queue message format to reference the stored payload.
Store the payload in a blob container, retrieve the blob's URI, and write the URI as the text payload of the queue message.
This allows the queue message size to remain extremely small (under 1 KB) while referencing the full payload.
4
Design the worker processing and cleanup workflow.
The worker reads the queue message, retrieves the payload from Blob Storage using the URI, processes the request, and deletes both the queue message and the blob.
Deleting the blob prevents orphaned storage files and manages storage costs.

Key Concept

Handling messages that exceed the 64 KB Azure Queue Storage size limit.
Rate this question