EPIC: Strava rate limits (Cross-project)

[obscurerichard]

After hitting rate limit problems with freezing-sync yet again, and patching it up in a hacky way, see freezingsaddles/freezing-sync#69 and https://github.com/freezingsaddles/freezing-sync/blob/7dd8d5286e09b62c50ecae2be7c2f5e36af44607/freezing/sync/subscribe.py#L108-L109 - it's clear that we need a better solution. This has caused problems for years going back to 2016.

Towards a comprehensive solution for enforcing cross-component rate limits

While stravalib has multiple options for rate limiting built in, its implementation assumptions with the built in throttle classes are that it the throttling is done per Client, except maybe with the Sleep rate limiter that I have not tested - and given that each athlete's connection to Strava requires constructing a new Client object, and multiple Clients from different processes (freezing-nq, freezing-sync, and freezing-web) all have to cooperate, using a distributed rate limiting scheme such as a token bucket filter in conjunction with Redis or its open-source fork Valkey is likely in order.

It may even be possible to put a custom rate limiter class directly into the stravalib client constructor to handle this really smoothly.

References

• https://en.wikipedia.org/wiki/Token_bucket
• https://stravalib.readthedocs.io/en/v2.1/get-started/overview.html#rate-limits
• https://pypi.org/project/token-throttler/
• https://github.com/Windfarer/redis-token-bucket
• https://github.com/krishan/redis_token_bucket
• https://redis.io/glossary/rate-limiting/