Ruminating on Rate Limiting

As architects, when we define the API strategy for any organization, we also need to design the 'Rate Limiting' features for that API. The concept of Rate Limiting is not new and the term has been used in networking world for long to represent the control of rate of traffic over the internet.

Other common examples of Rate Limiting that we see very often are as follows:

1. Limit consecutive wrong password entries to 3.
2. Maximum size of an email attachment.
3. Max number of emails one can send in a day.
4. Max number of search queries one can fire every minute.
5. Max. broadband download size per day, etc. 

Rate Limiting is also an important line of defense from a security perspective. Jeff Atwood has a good blog post on 'Rate Limiting' available at: http://blog.codinghorror.com/rate-limiting-and-velocity-checking/

For services or APIs, there are standard ways in which we can rate limit the requests. For e.g.

• Based on API key: This is how Twitter rate limits their API. Each account with a API key can only make x requests/{time period}. For e.g. 10 requests every 5 mins, 500 requests per day, etc.
• Based on IP address: This may not work behind a proxy due to NATing.