Bound Table Storage retry concurrency before increasing request volume

Source facts

Microsoft’s Table Storage checklist calls for bounded parallelism and exponential-backoff retries for throttling errors and timeouts. It also calls for avoiding retries of errors that are not retryable. The guide associates approaching or exceeding scalability targets with higher latency or throttling, including Server busy and Operation timeout responses. Microsoft Learn

Applicability

Use this review for an Azure Table Storage application showing throttling or timeout behavior while its request concurrency or retry settings are being tuned.

DSE recommendation

DSE recommends capturing request rate, concurrent work, error categories, and retry behavior from the same representative workload period. Separate retryable failures from errors that need a configuration or application fix. Define an upper bound on parallel work and a testable backoff policy before raising throughput. Ask the application owner to specify acceptable completion time and error behavior so the experiment has a clear stopping point.

Verification

Run a bounded test and compare the request, retry, latency, and completion observations with the starting evidence. Confirm that retries follow the intended policy and that non-retryable failures remain visible. Keep a higher request count from being reported as an improvement unless useful work completes within the agreed criteria.

Official references

• Microsoft: Performance and scalability checklist for Table storage – Azure Storage | Microsoft Learn