In my experiments and according the documentation, for volatile keys (expired keys), INCR will overwrite the value, treating it as null; your counter will forever be 1 if you use expire.

incr(‘foo’,1)
# foo = 1 # good
incr(‘foo’,1)
# foo = 2 # good
expire(‘foo’,100)
# foo will expire in 100 seconds
incr(‘foo’,1)
# foo = 1 # bad

See this thread:
http://groups.google.com/group/redis-db/browse_thread/thread/9de9fdb23d9b04c2

Using a cron job for cleanup seems to be a reasonable approach to this problem

http://code.google.com/p/redis/wiki/ExpireCommand

INCR then EXPIRE a key.

The nice part about the EXPIRE command is that you get a running rate limiter, as a pending expiration is removed after you change a value.

INCR key, EXPIRE key 3600.

@Leather – not everyone can control the nginx config (e.g. when hosted on Heroku).

Limit_req is great, but it doesn’t have flexibility of a higher level tool like ApiThrottling. Being able to limit on a per-user basis make ApiThrottling a heck of a lot more useful. It’s pretty common with API services to limit requests based on contractual agreements (pay more for a higher guaranteed throughput, etc). This could be built into ApiThrottling without much work.

Also, starting off a comment with “this is stupid” is pretty asinine, especially when you obviously haven’t spent the time to understand what ApiThrottling gives you. Luc has made something really great here, and trolling just makes you look, well, stupid.

Thanks for your comment. I did look at the limit_req module but the documentation was sparse and it didn’t seem to be able to limit connections per user.

If you have used limit_req before, it would be great if you could write about it and share your knowledge since there is so little documentation on it. I would love to see a solution to this problem using limit_req module.

Rack and redis are not really a overhead. All Ruby frameworks use rack it and if you run any modern Ruby web framework, you are already using it heavily + we are using Redis for other stuff to so it is part of our infrastructure. If you do not want to use Redis and have Memcached already running, you could easily adapt this code to use memcached instead (see Mike’s comment earlier).

Use the right tool for the right problem. There is no need to include all of this at such a high level.

For example, nginx has the limit_req directive that works perfectly for something like this. There is no need to incur all the additional overhead of rack, redis blah blah blah.