3 ms·
agreed. I was a bit leery of diving into Lua as I was building http://ratelim.it http://ratelim.it but it really expands Redis's capabilities dramatically and w
by jdwyah 10y ago
agreed. I was a bit leery of diving into Lua as I was building http://ratelim.it http://ratelim.it but it really expands Redis's capabilities dramatically and was easy enough to add.
My apps all write the lua into redis and store the hash when they boot up. Duplicative, but means everybody is on the same page and it's easy to store the lua in the main codebase.
- wpeterson 10y agoHey buddy! Reading all the design and discussion I was. Rey curious how you structured things at a brass tacks storage level.
- jdwyah 10y agoyoo! https://www.slideshare.net/jdwyah/diy-heroku-using-amazon-ecs-and-terraform https://www.slideshare.net/jdwyah/diy-heroku-using-amazon-ec... does have a bit of a pretty picture, but the basic idea is: For each rate limit you can choose to be in one of two modes: 1) Redis with a backing store of DynamoDB aka BestEffort since there are failure modes where you could lose an update. In this mode everything expects to happen in Redis, but if we don't find your limit there we check Dynamo. Writes are asynchronously persisted to Dynamo. 2) Token Buckets straight in DynamoDB. This is our Bombproof mode. (details in https://www.ratelim.it/documentation/safety https://www.ratelim.it/documentation/safety) It's worth noting that with either of these you can cache aggressively in the clients whenever the limits have gone over. Both the clients https://github.com/jdwyah/ratelimit-ruby https://github.com/jdwyah/ratelimit-ruby https://github.com/jdwyah/ratelimit-java https://github.com/jdwyah/ratelimit-java do that for you.
- deleted 10y ago[deleted]