Maybe he doesn't have a company because he is too dogmatic about things that don't really matter.

100%

People who have takes like this have likely never zoomed out enough to understand how their software delivery ultimately affects the business. And if you haven't stopped to think about that you might have a bad time when it's your business.

Someone has to question the status quo. If we just did the same things there would be a lot less progress. The author took the time to articulate their argument, and publish it. I appreciate their effort even if I may not agree with their argument.

Bingo. Everything that can be wrongly used or abused started out its existence within sane constraints and use patterns.

Amazing how many people have strong feelings about an Ad about the iPad.

Given most of the backends use round robin for loadbalancing, having in-memory counter should be enough. Removing redis as downstream dependency is a big win.

For the redis implementation, there should be fallback to in-memory counting instead blocking altogether. Currently the redis is a SPOF for the entire service.

if you're round robining clients w/o sticky assignment then you're going to get nodes*limit consumption. Not correct.

Also if you give limit/nodes per node and random assign a connection, you get correct answers on average, but a really janky pattern at the edge case (a user gets a 429, and retries and succeeds, then gets 429 again as they consume those last few requests).

> if you're round robining clients w/o sticky assignment then you're going to get nodes*limit consumption. Not correct.

Fair point, using in-mem storage changes the meaning of the limit, since accounting changes to local. Something to consider in the library API.

> Given most of the backends use round robin for loadbalancing, having in-memory counter should be enough. Removing redis as downstream dependency is a big win.

thanks for the feedback. planning to make redis optional in next release.