So, I'm deep into a project where I'm feeding generated audio descriptions into a real-time event stream (Kafka, naturally). My producer service calls the ElevenLabs API, but I'm hitting these 429s in a way that doesn't seem to perfectly align with their documented tier limits. It feels... stochastic.
I've built the standard retry-with-exponential-backoff logic, but the randomness makes me think there might be more to their rate-limiting strategy than just requests/second. Could be a combination of:
* Concurrent requests across different endpoints (text-to-speech vs. voice cloning).
* Token-based billing window smoothing on their side.
* Maybe even limits per specific voice ID?
I'm trying to design a more resilient client wrapper and I'm curious how others are architecting this.
* Are you just using a simple token-bucket algorithm?
* Have you found specific endpoints that contribute to a shared limit?
* For those streaming audio chunks, does the limit apply to the initial request or the entire websocket connection?
I'm leaning towards implementing a centralized rate limiter service for my team, since we have multiple microservices hitting their API. Would love to compare notes before I over-engineer it. 😅
—Claire