I am making an android app which will talk to a web service to get data. The web service has a rate limit of 100 calls per minute. Is there a way, recommended method to ensure that the app across various devices dont make the call to the server at the same time. Some way to stagger the requests across devices?
1
-
Is this 100/minute imposed by cost where the ISP will charge you for overage? You might want to look at a more flexible plan if you expect more or variable traffic as @JonathanEunice discusses below.– mswOct 8, 2014 at 23:54
Add a comment
|
4 Answers
Essentially you would need to proxy that web service with one of your own that does rate limiting. The devices wouldn't know anything about each other, and you can cache/re-implement the service if you need to scale further.
If your app is going to have a very small user base (say a corporate app, with less than a few hundred users), then you can make each client rate-limit itself to check the server less than once every N/100 seconds, where N = number of clients. Add in a little extra delay as a margin of safety, and perhaps randomize that margin a bit to lower the likelihood that clients happen to bunch up on any given instant.
But beware, this is a very low-end solution. It can work adequately for very small user bases, especially if they need very infrequent updates. This is essentially how the Twitter and Facebook feed plugins for WordPress blog sites work.
But if your app is at all popular, there is no way that 100 requests/minute will suffice. None whatsoever. In that case, @Sign's proxy service is the way to go. If the app is very successful, the proxy will even need to be a multi-machine cluster with load-balancing, caching, high-availability failover, and so on.
answered Oct 8, 2014 at 21:24
-
2I was just about to type this out when I saw "new answer received" appear. :-) Another variant that is used for collision detection in networking is basically to make the endpoint have two behaviors. One is simply to provide the response as expected, and the other is to send back a message that basically says "I'm busy, try again in a random interval of time, not to exceed XXXXX milliseconds". When the client gets that second message, it waits a random amount of time less than it was told, and tries again. The responsiveness of the apps can be tuned by the endpoint's "XXXXX" figure.– CalphoolOct 8, 2014 at 21:30
-
3Exactly. Backoff and retry algorithms can get quite sophisticated. One important caution: Some rate-limiting services seem to consider requests, not successful requests. So failed requests count against the quota. If you get a convoy of many clients backing off and retrying, starvation can occur. In that case, better to err on the side of conservatism, and use large safety margins. Oct 8, 2014 at 21:41
You are essentially trying to do collision detection the same way ethernet and other network protocols perform collision detection for network packets in a distributed setting. The problem is that you don't have the benefit of the protocol being aware of such scenarios if you're talking to a server that you don't control. The only real solution in that case is to proxy all requests through an intermediary that you do control and then make it aware of collisions. Instead of a wire like in the case of ethernet you essentially have 100 wires each of which can only have one request active. Here's an article that should be helpful: Carrier sense multiple access with collision detection.
you need to implement a queue, not collision detection, when packets collide they are resend after the verifications, you have limited resources, if your detecting collision and resending data all the time, you can have a lot of problems with your hosting.
A time oriented queue, using time as metric you can control how much requests per minute you are handling without resending data.
Just saying.