Live data from Hacker News

An Interactive Guide to Rate Limiting

blog.sagyamthapa.com.np

11–20 of 48 posts

Re: An Interactive Guide to Rate Limiting

#11
I’ve found the AIMD algo (additive increase, multiplicative decrease) paired with a token bucket gives a nice way to have a distributed set of processes adapt to backend capacity without centralized state.

Also found that AIMD is better than a circuit breaker in a lot of circumstances too.

Golang lib of the above https://github.com/webriots/rate

Re: An Interactive Guide to Rate Limiting

#12
Something I’ve long wondered is why you never hear about rate limiting algorithms that are based on the cost to serve the request or algorithms that dynamically learn the capacity of the system and give everyone a fair share.

In the field of router buffer management, there are algorithms like Stochastic Fair Blue, which does the latter, but is somewhat hard to apply to HTTP because you’d have to define a success/failure metric for each request (a latency target, for example), and clients would have to tolerate a small probability a request being rejected even when they’re not being rate limited.

In Google’s paper on the Zanzibar authorization system, they give brief mention to rate limiting clients based on a CPU time allocation, but don’t go into any detail since it’s not a paper on rate limiting.

It’s something that matters less today with ubiquitous autoscaling, where the capacity of the system is whatever you need it to be to give each user what they ask for up to their rate limit, but I’m surprised at my inability to find any detailed account of such a thing being attempted.

Re: An Interactive Guide to Rate Limiting

#13
post #3

I wonder if anyone has switched algorithms after hitting real-world scaling issues with one of those? Curious if there are any “gotchas” that only show up at scale. I only have experience with fixed window rate limiting

We used leaky bucket IIRC and the issue I saw was that the distributed aspect of it was coded incorrectly and so depending on the node you hit you were rate-limited or not :facepalm:

Re: An Interactive Guide to Rate Limiting

#15
post #12

Something I’ve long wondered is why you never hear about rate limiting algorithms that are based on the cost to serve the request or algorithms that dynamically learn the capacity of the system and give everyone a fair share. In the field of router buffer management, there are algorithms like Stochastic Fair Blue, which does the latter, but is somewhat hard to apply to HTTP because you’d have to define a success/fail…

Yes, autoscale is a thing but it's rarely instantaneous ; you'll still benefit from having a good handle on load fairness.

Furthermore, modern GPU workloads are way less elastic in capacity scaling

Re: An Interactive Guide to Rate Limiting

#16
post #8
post #4

Super cool. What did you use to build the interactive bits?

It really looks AI generated

Yes, I usually prompt (Claude, GPT and Deepseek),on my rough vision, and take ideas from all of them. They never quite get it right on their own. But for a code that's deploy and forget, AI generated code is good enough.

Re: An Interactive Guide to Rate Limiting

#18
This seems like someone used AI to generate the article and examples without much review. It's all bullet points, and it repeatedly uses "Working:" as a heading, which doesn't make any sense to me.

The site defaults to dark mode for me (I'm assuming based on my system preferences), but all the examples are unusable with dark mode. The examples all seem to be within fixed-width divs that cut off part of the content unless you scroll within the example.

Re: An Interactive Guide to Rate Limiting

#20
post #12

Something I’ve long wondered is why you never hear about rate limiting algorithms that are based on the cost to serve the request or algorithms that dynamically learn the capacity of the system and give everyone a fair share. In the field of router buffer management, there are algorithms like Stochastic Fair Blue, which does the latter, but is somewhat hard to apply to HTTP because you’d have to define a success/fail…

Shuffle-sharding is similar to stochastic Blue stuff, and you'll find Amazon talking about it:

https://aws.amazon.com/builders-library/workload-isolation-u...

Which isn't exactly what you're talking about, but between that and other things in the "Builder's Library" series, you can see that people are doing this, and writing about it.

Post reply on HN