スピーチ・トゥ・テキストの作業は、レート制限を効果的に処理するために、耐久性のあるキューで管理する必要があります。システムは、429レスポンスのRetry-Afterヘッダーを尊重し、時間とともに解決しないエラーのリトライを避ける必要があります。主な制約は、HTTPクライアントだけでなく、文字起こし機能の可用性です。ジョブは冪等性キーで受け付けられ、最初は保留状態を返し、その後、バウンドされたワーカーがプロバイダーを呼び出します。リトライをトリガーするのは、429と一時的なサーバーエラーのみであり、Retry-Afterは正しく解析され、ジッターが追加されます。キューはレート制限のバーストを吸収できますが、利用できないASRバックエンドを利用可能にすることはできません。開発者ツールの場合、Webリクエストと文字起こし処理を分離することが重要であり、パイプラインが保留中、実行中、失敗、完了などの状態を正確に報告できるようにします。429レスポンスはサービスが一時的に利用できないことを示しますが、その他の4xxエラーは即時のロギングとリトライなしを必要とする永続的な問題を示します。本番トラフィックを送信する前に、システムはディスカバリデータを通じてバックエンドの準備状況を確認する必要があります。バルク送信はバックエンドの準備状況を変更せず、「ローカルでキューイング済み」や「プロバイダーによって受け付け済み」などの状態は区別されたままにする必要があります。マルチパートリクエストのリトライにはボディの再作成が必要であり、大きなファイルの場合はバッファリングを避けることが不可欠です。冪等性は、リトライによる重複した副作用を防ぐために不可欠です。キューの受け入れポリシーには、オブジェクトの永続化、ジョブレコードの書き込み、および202 Acceptedステータスの返却が含まれるべきです。ワーカーは、グローバルおよびテナントごとの同時実行制限を強制する必要があります。状態遷移は、リトライ、永続的な失敗、およびキャンセルを明確に区別する必要があります。スピーチ・トゥ・テキストプロバイダーの選択は、統合、運用上の境界、および準備状況に依存します。最後に、正しいリトライロジックを確保するために、制御されたサーバーレスポンスでステートマシンをテストする必要があります。