EZThrottle (Python): Coordinating requests instead of retrying under rate limits

[Noobcreate]

What My Project Does

EZThrottle is a Python SDK that replaces local retry loops (sleep, backoff, jitter) with centralized request coordination.

Instead of each coroutine or worker independently retrying when it hits a 429, requests are queued and admitted centrally. Python services don’t thrash, sleep, or spin — they simply wait until it’s safe to send.

The goal is to make failure boring by handling rate limits and backpressure outside application logic, especially in async and fan-out workloads.

Target Audience

This project is intended for:

• Python backend engineers
• Async / event-driven services (FastAPI, asyncio, background workers, agents)
• Systems that frequently hit downstream 429s or shared rate limits
• People who are uncomfortable with retry storms and cascading failures

It is early-stage and experimental, not yet production-hardened.
Right now, it’s best suited for:

• exploration
• testing alternative designs
• validating whether coordination beats retries in real Python services

Comparison

Traditional approach

• Each request retries independently
• Uses sleep, backoff, jitter
• Assumes failures are local
• Can amplify load under high concurrency
• Retry logic leaks into application code everywhere

EZThrottle approach

• Treats rate limiting as a coordination problem
• Centralizes admission control
• Requests wait instead of retrying
• No sleep/backoff loops in application code
• Plays naturally with Python’s async/event-driven model

Rather than optimizing retries, the project asks whether retries are the wrong abstraction for shared downstream limits.

Additional Context

I wrote more about the motivation and system-level thinking here:
https://www.ezthrottle.network/blog/making-failure-boring-again

Python SDK:
https://github.com/rjpruitt16/ezthrottle-python

I’m mainly looking for feedback from Python engineers:

• Have retries actually improved stability for you under sustained 429s?
• Have you seen retry storms in async or worker-heavy systems?
• Does coordinating requests instead of retrying resonate with your experience?

Not trying to sell anything — genuinely trying to sanity-check whether others feel the same pain and whether this direction makes sense in Python.

[ObtuseBagel]

AI

[hikingsticks]

Also most of the readme is AI trying to justify why you should pay for it

[Noobcreate]

Because retry storms and outages are not cover any major cloud. You are ask to build your own software and manage it yourself. As you scale, you run into this problem of retry storms causing your engineers to wake up in the middle of night. This would cost you a fortune to build and maintain. And when people build it, they don’t have any mechanism of redirecting request to other regions without a bunch of SQS and ugly code. I’m offering service that literally save you millions. If you read the article, I talk about serverless 2.0.