
Rate limiting with memcached - danw
http://simonwillison.net/2009/Jan/7/ratelimitcache/
======
teej
I'm not one to peddle my own wares, but Alchemy (distributed memory array
storage) fits the bill for a slightly more elegant solution. Think of a hash
with key => array pairs.

With Alchemy, you can just stuff the times of your most recent "actions" into
a key. Here's a Ruby psuedocode example:

    
    
        alchemy[ratelimit_72.26.203.98_2009-01-07] << 1.minute.ago
        alchemy[ratelimit_72.26.203.98_2009-01-07] << 20.seconds.ago
        alchemy[ratelimit_72.26.203.98_2009-01-07] << 5.seconds.ago
    
        alchemy[ratelimit_72.26.203.98_2009-01-07].select{ |e| e > 30.seconds.ago }.size
    

In that brief example we've defined a true rolling window (30 seconds) with
the ability to grab the true count of actions performed (size) with only one
cache query. And similar to the pure memcached version the article suggests,
you don't have issues with race conditions.

~~~
simonw
Where can I find more information about Alchemy?

~~~
teej
<http://github.com/teej/alchemy/tree/master>

------
ned
In this age of massive botnets, I don't see the point of grouping the requests
by IP address, as he suggests: the attacker will just use his 500000 different
machines to attack a single account.

So you should probably keep track of the username or account ID that the
request is being made for, and rate limit on that.

