The week before last I touched on an issue raised by an Operations Engineer at Twitter in a recent presentation he gave. This was the impact huge amounts of abusive requests can have on the performance of a service and why applying rate limiting is so important to Twitter.
For some businesses, individual users may try to dominate the use of a particular service, to the detriment of other users of the service, and a business may have limited scalability in terms of their back-end application infrastructure, which would become easily overwhelmed when too many requests are given to it. This is when a business may wish to restrict the rate at which certain activities can occur, such as sending an email, or logging in to a service, as-part of a threat management policy.
This got me thinking about the issue in a little more detail. I, like many others, access Twitter via TweetDeck using the API and experience the rating limiting when I would least expect to. This is at times when the service should be relatively quiet and the infrastructure is not overstrained.
What is interesting to note (thanks to @r4yfx for the stats) is that 75% of Twitter traffic is allegedly sent using the API (3 billion calls a day). That could mean that a large proportion of users of the service could be experiencing the kind of inconvenience I experience at exactly the point when they need to update their status, especially if the message is work related. It may be that as twitter scales its services, it plans to throw more load balancers and app servers at the service. But, the current Twitter solution to rate limiting does seem to lack a certain elegance. Could this be deliberate? If so, what is the business logic behind it?
At Zeus, we might suggest a slightly different approach to the problem of who and how to rate limit, especially if you are unable to throw more infrastructure resource at the issue. Perhaps it might be that rate limiting only take place when the infrastructure is under particular strain.
In the next part of this post, we explore what the first steps would be from a Zeus perspective towards addressing the issue of rate limiting and highlight a Zeus customer example.
Mark Gyles
Comments