Speech-to-text work should be managed by a durable queue to handle rate limiting effectively. The system must respect the Retry-After header on 429 responses and avoid retrying errors that won't resolve with time. The primary constraint is the availability of the transcription capability, not just the HTTP client. A job is accepted with an idempotency key, initially returns a pending state, and a bounded worker then calls the provider. Only 429 and transient server errors should trigger retries, with Retry-After parsed correctly and jitter added. A queue can absorb rate-limit bursts but cannot make an unavailable ASR backend available. For developer tools, separating the web request from transcription processing is crucial, allowing the pipeline to report states like pending, running, failed, or complete authentically. A 429 response indicates the service is temporarily unavailable, while other 4xx errors signify permanent issues that require immediate logging and no retries. Before sending production traffic, the system must verify backend readiness through discovery data. Bulk submissions don't change backend readiness; states like "queued locally" and "accepted by provider" should remain distinct. Retrying multipart requests necessitates recreating the body, and for large files, avoiding buffering is essential. Idempotency is vital to prevent duplicate side effects from retries. Queue admission policy should involve persisting objects, writing job records, and returning a 202 Accepted status. Workers should enforce global and per-tenant concurrency limits. State transitions should clearly distinguish between retries, permanent failures, and cancellations. The choice of speech-to-text provider depends on integration, operational boundaries, and readiness. Finally, testing the state machine with controlled server responses is necessary to ensure correct retry logic.