Thanks for the explanation. I see a few corrections in your implementation: 1. UserBucketCreater should not be initialised for each and every user. In the constructor you are keeping Map which is initialised per user and for every user there will be one map with only one key. The map will be initialised for the whole app and should have different LeakyBucket per user. 2. If there is no entry in the map for a specific user, we have to add one and the increment.
Yes, that's what my point is, a local map will be replaced by redis and then each user in redis will have a separate bucket. Here you are initialising map every time as part of UserBucketCreator and it should be common to the application, be it local or distributed. Am I missing something?
Great implementation and very well explained! I think one minor fix on the code, instead of initializing the map in the BucketCreator constructor, you could take the map as a static variable.
Nice video. Thanks. I had a small doubt, shouldn't the type of bucket be Map instead of Map ? For strategy pattern we should not use concrete definitions. What do you think?
Do we need the capacity check, I think the add method will throw an exception in case of no remaining space in the queue. Can we wrap this in a try catch and return the exception instead of false ?
You are right. I did not add any consumer, to keep the focus on leaky bucket implementation, rather than complicating it into a producer, consumer model.
I have few questions here, In non distributed system when u had leaky bucket for every IP and you restrict 10 request per min from 1 IP. Lets say queue size is 20 and we get request from multiple IP's and queue gets filled for first IP we could use only 3 requests out of 10 and queue got filled, it still had quota but it is not allowed to send the request, Is this correct, Please correct me if my understanding is wrong here.
there is " leaky bucket for every IP" which means there is a blocking queue for every IP. In a queue size of 20, queue can not reach it limit with just 3 requests from that IP. It will still have the quota for that IP and it will allow
Thanks for the explanation. I see a few corrections in your implementation:
1. UserBucketCreater should not be initialised for each and every user. In the constructor you are keeping Map which is initialised per user and for every user there will be one map with only one key. The map will be initialised for the whole app and should have different LeakyBucket per user.
2. If there is no entry in the map for a specific user, we have to add one and the increment.
How will you scale this implementation? What happens when we have application running on distributed server?
Yes, that's what my point is, a local map will be replaced by redis and then each user in redis will have a separate bucket. Here you are initialising map every time as part of UserBucketCreator and it should be common to the application, be it local or distributed. Am I missing something?
Great implementation and very well explained! I think one minor fix on the code, instead of initializing the map in the BucketCreator constructor, you could take the map as a static variable.
This doesn't look like a leaky bucket? You are not leaking requests at a fixed rate.
yes this is shitty bucket
Buddy, you have to make the UserBucketCreator Map to be static otherwise your Map will only contain 1 userEntry.
Nice video. Thanks. I had a small doubt, shouldn't the type of bucket be Map instead of Map ? For strategy pattern we should not use concrete definitions. What do you think?
Do we need the capacity check, I think the add method will throw an exception in case of no remaining space in the queue. Can we wrap this in a try catch and return the exception instead of false ?
lets say you are using redis for distributed cache ...would not we have race conditions there ? if yes how to deal ?
You are not removing requests from bucket! Need to fix this code.
He did say that in the real world services would consume the items from the queue
Good One. But couldn't find any where you removing the elements from blocking queue. Am i missing something?
You are right. I did not add any consumer, to keep the focus on leaky bucket implementation, rather than complicating it into a producer, consumer model.
@@TheTechGranth Noted Thanks :)
@@ankitnigamrocks Hope it was helpful. Do like and subscribe and share with others 🙂
@@TheTechGranth yes i liked. Am i already a subscriber. You are doing good job. Keep up. Thnxks
One Could simply add a AtomicLong lastLeakedTime & Leak() method. Inside Leak(), take() from blocking queue number of expected leaks till now.
I have few questions here, In non distributed system when u had leaky bucket for every IP and you restrict 10 request per min from 1 IP. Lets say queue size is 20 and we get request from multiple IP's and queue gets filled for first IP we could use only 3 requests out of 10 and queue got filled, it still had quota but it is not allowed to send the request, Is this correct, Please correct me if my understanding is wrong here.
there is " leaky bucket for every IP" which means there is a blocking queue for every IP. In a queue size of 20, queue can not reach it limit with just 3 requests from that IP. It will still have the quota for that IP and it will allow
try testing this with more than one user and multiple requests.
good one, can you share the code link?
GitHub link is there in description