I am designing a system to copy files to/from Dropbox via the HTTP API using AWS Lambda functions.
We may be copying large quantities of files (up to 10,000 in a batch) using a single API key. As you may know, AWS Lambda can fire thousands of Lambda functions simultaneously. This could mean that the API gets hit with thousands of requests in a very short period of time (a window of a few seconds) I think I will probably start running into 429 responses (rate limiting) if we send this volume of requests to in such a short window.
Does anyone know what the best practice would be for this use case? Is there a maximum number of simultaneous connections allowed by the Dropbox API?
Solved! Go to Solution.
Thanks for this info.
I understand the exponential backoff and the Retry-After header, no problem.
I'm trying to understand what happens in a hypothetical situation in which a lot of Lambda functions fire in parallel. Let's say we have 200 functions all making API calls within a few seconds, and (hypothetically) the 143rd Lambda triggers rate limiting. The 144th through 200th functions will be already attempting to make API calls before the 143rd function could circulate a message that the other Lambda functions that they should not attempt API calls until after the time specified in the Retry-After header.
Will we be penalized in any way for the remaining functions (144-200) attempting to call Dropbox endpoints before the time specified in the Retry-After header in the response to 143?
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.