When a user creates their account they're given a rate_limit attribute. This is used to determine their allocation per hour. Currently those accesses are split within the hour by the constant, split_factor. It will be straightforward to change this scheme if we think there's a better way.
Upon making a request, we look for a key in redis, rate:<TOKEN>. If it's found, we make sure they still have requests let before decrementing it. If not, we find their allocated rate from postgres and create an expiring key (life: 60 minutes / split_factor) with a value = limit/split_factor before decrementing it and allowing the request.
When a user creates their account they're given a
rate_limit
attribute. This is used to determine their allocation per hour. Currently those accesses are split within the hour by the constant, split_factor. It will be straightforward to change this scheme if we think there's a better way.Upon making a request, we look for a key in redis,
rate:<TOKEN>
. If it's found, we make sure they still have requests let before decrementing it. If not, we find their allocated rate from postgres and create an expiring key (life: 60 minutes /split_factor
) with a value =limit
/split_factor
before decrementing it and allowing the request.I wrote a mocked test as well as an integration test.
closes #13 & closes #71 This necessitated adding a
rate_limit
column to theusers_t
table in Postgres