App architecture to avoid Spotify Web API rate penalizing
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are developing an app with the Web API, and have a basic architecture problem. We do understand 429-RetryAfter-backoff. That part is fine.
But even if we handle HTTP 429's correctly, our major concern is that our users will all be coming from different IP addresses. How can we stop accidentally triggering the 12 hour or 24 hour block if we have a normal spike in user traffic from many users at once? Are developers expected to proxy Spotify API calls through our own central server to control rate better (that doesn't seem right)?
My hope -- will Spotify be forgiving of traffic spikes as long as the (potentially very many) user browsers calling from different IP addresses each follow the 429-backoff independently? Or will it penalize us if a bunch of our users happen to hit the API at the same time?
Can anyone share the actual rolling 30 second rate limit number? We are basically doing searches for tracks as a user types.
The 429 backoff doesn't scare us, it's fine, however the 12 or 24 hour lockout we have seen other API users report would be a huge problem.
- Labels:
-
Question
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page