It was really quite the let down of an article. All that build up, then basically nothing about <i>how</i> adaptive rate limiting would be implemented in practice, how expensive it would be, what it requires, the challenges it involves, etc.
No surprise that it's not already implemented because we just throw more cheap hosting and bandwidth at this problem until it's fixed.<p>The "premature optimization is the root of all evil" misquote really caused a lot of damage to favor growth and profit making instead of better software. It seems programmers have a general habit of just implementing things in the most naive and cheap way and just solve any problem with expensive hardware.<p>We really need a new trend of fast and minimal software because climate change and a finite planet will not allow us to follow Wirth's law for very long.
Not sure it "changed my game" but I have a process that I run on many files at once. In a *nix I would run the processes like so:<p><pre><code> for i in list_of_files; do
run_intensive_process &
sleep $(awk '{print $3}' < /proc/loadavg)
done
</code></pre>
As more processes start upping my load average, it sleeps longer before running each one in the background. I guess GNU parallel can do this sort of thing with a load-sensitive command line arg, but I find this pattern easy to remember, and parallel's decidedly not.<p>Works for me.
I don't believe that Twitter has to limit requests to avoid bots.<p>They would just have to limit requests by IP and thats it. Say 10 tweets per IP per day. For requests which do not come from logged in users.<p>I can't see how scrapers would be able to come up with enough IPs to make a dent in Twitters costs.
I feel this has potential to bring new levels of painful ux.<p>> They might prioritize serving the VIPs and slow down the pace when there is an influx of newcomers.<p>Or they might prioritize people who are about to convert and deprioritize them once they pay.
The biggest problem with adaptive rate limiting is that, in many contexts, clients value predictability more than they do peak performance. Adaptive rate limits change client behavior in ways that clients can't predict or control.<p>Even in networking, the classic application domain of adaptive rate limits (like TCP's algorithms), core networks are built to offer predictable performance. Edge networks, like public WiFi, that offers best-effort performance with adaptive rate limits, are often met with frustration and even anger the moment those limits kick in.