Multiple documents in the same container and folder

Question

Suppose I have the following blob names inside the same container and virtual folder:

invoices/2026/jan/invoice-001.pdf
invoices/2026/jan/invoice-002.pdf
invoices/2026/jan/invoice-003.pdf

Would each of these files be considered a separate blob, meaning:

• Each has its own blob name
• Each has its own partition key
• Each counts as an independent transaction?

Occasionally during heavy upload or download operations, I see intermittent failures such as:

• Timeouts
• 503 (Server Busy)
• Connection resets

From what I understand, these types of failures are considered network transient errors—temporary issues that resolve when retried. Azure documentation mentions that when partition limits are approached, Azure may return 503 Server Busy or Operation Timeout, and the recommended mitigation is to use exponential backoff retry policies.

Is my understanding correct that these transient issues are normal in distributed systems and should be handled with retries rather than indicating a persistent problem?

Answer 1

Yep - in Azure Blob Storage every stored object is a separate blob, regardless of how its name appears to represent folders.

In your example each of the following is a distinct blob:

invoices/2026/jan/invoice-001.pdf
invoices/2026/jan/invoice-002.pdf
invoices/2026/jan/invoice-003.pdf

Azure Blob Storage does not actually store directories. The forward slashes are simply part of the blob name used to simulate a hierarchical structure. Each of these entries therefore has its own unique blob name and is treated as an independent object.

Because each blob is an independent object, operations on them are also independent. Each upload, download, read, write, delete, or metadata operation counts as its own transaction against the storage account. The platform internally partitions data based largely on blob name ranges so that load can be distributed across storage nodes. Although the exact partition key mechanism is internal to Azure and not directly exposed, different blob names are independently addressable and may be placed on different partitions depending on the service’s partitioning logic.

The intermittent failures you described—timeouts, HTTP 503 Server Busy responses, and connection resets—are typical examples of transient faults in large distributed storage systems. These can occur due to temporary load spikes, network congestion, partition rebalancing, throttling when throughput limits are approached, or short-lived infrastructure events. Azure Storage documentation explicitly classifies 503 Server Busy and operation timeouts as signals that the service is throttling or temporarily unable to process the request at that moment.

The correct pattern is to implement retry logic with exponential backoff. A simple conceptual pattern looks like:

delay = base * (2 ^ retry_attempt) + random_jitter

The jitter component is important to prevent many clients from retrying at exactly the same time and creating synchronized spikes.

Azure SDKs already implement robust retry policies that follow this pattern, so in most applications you should rely on the SDK’s built-in retry behavior or configure it appropriately. When transient failures succeed after retries, they are considered normal operational behavior in distributed systems and do not indicate a persistent problem with the storage account. Only if retries consistently fail or error rates remain high would it suggest an underlying configuration, scaling, or networking issue.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin