You are developing an Azure Functions app that processes orders. Each order triggers a function that writes to Azure Cosmos DB. You notice occasional throttling (429 errors) from Cosmos DB during peak hours. The function app uses the Consumption plan. What is the most cost-effective way to reduce throttling?
Implementing retry logic with exponential backoff is a highly effective and recommended pattern for handling transient faults, including throttling, in distributed systems. When a downstream service like Cosmos DB temporarily throttles a request, the function can automatically retry the operation after progressively longer delays. This approach allows the throttled service time to recover, reduces the immediate load, and ensures eventual success without incurring additional infrastructure costs, making the function more resilient.
Why this answer
Implementing retry logic with exponential backoff is the most cost-effective way to handle transient 429 errors from Cosmos DB. The Azure Cosmos DB SDK already includes built-in retry policies, but custom retry logic in the function code can be tuned to match the workload, allowing the function to wait and retry during peak throttling without incurring additional costs from scaling or increasing throughput.
Exam trap
The trap here is that candidates often assume scaling the function app (Option C) or increasing Cosmos DB throughput (Option A) are the only ways to handle throttling, but they overlook that retry logic is a zero-cost, built-in mechanism that directly addresses the transient nature of 429 errors in a Consumption plan environment.
How to eliminate wrong answers
Option A is wrong because increasing provisioned throughput (RU/s) directly increases monthly costs, and it does not address the root cause of throttling during peak hours—it simply raises the ceiling, which is not cost-effective for sporadic bursts. Option B is wrong because upgrading to the Premium plan adds fixed costs for dedicated instances and always-on benefits, which are unnecessary when the Consumption plan already scales automatically; the throttling is on the Cosmos DB side, not the function app's compute capacity. Option C is wrong because scaling out the function app increases the number of concurrent function instances, which can actually increase the request rate to Cosmos DB and worsen throttling, not reduce it.