Pengirim yang sibuk dapat menghabiskan anggaran permintaannya sebelum semua pesannya diantrekan. Membaca sisa kuota memungkinkan pengirim memperlambat laju sebelum lebih banyak panggilan ditolak.
Bagaimana Bird menentukan batas saya?
Bird menerapkan tarif dasar, peningkatan paket jika ada, lalu override untuk grup yang relevan jika ada. Override menggantikan nilai lainnya.
Endpoint terkait berbagi satu grup. Menghabiskan grup pengiriman tidak otomatis menghabiskan grup terpisah yang digunakan untuk membaca status atau mengelola webhook.
Cakupan setiap anggaran bergantung pada operasinya:
| Grup | Siapa yang berbagi anggaran? |
|---|---|
| Pengiriman produk | Semua kredensial dalam organisasi untuk produk tersebut. |
| Baca, daftar, dan tulis manajemen | Permintaan dari kredensial aktif yang sama dalam organisasi. |
| Login atau reset kata sandi tanpa autentikasi | Permintaan dari IP klien yang sama. |
Batas tanpa autentikasi menggunakan ambang tetap. Lihat panduan pembatasan laju permintaan untuk grup yang ditetapkan ke masing-masing endpoint.
Batas pengiriman menghitung permintaan, bukan penerima. Permintaan batch dapat mengantrekan beberapa pesan sekaligus. Grupnya mungkin memiliki kuota berbeda.
Bandingkan kuota aktif dan jumlah penerima yang dapat Anda kelompokkan sebelum beralih endpoint. Batch yang hanya berisi satu penerima mungkin tidak memberikan peningkatan throughput.
Bagaimana cara membaca header respons?
Baca RateLimit-Policy untuk kuota dan jendela waktu, lalu RateLimit untuk sisa permintaan dan waktu hingga reset.
Contoh:
RateLimit-Policy: "email_send";q=1000;w=60
RateLimit: "email_send";r=842;t=35Contoh ini mengizinkan 1.000 permintaan per jendela 60 detik. Tersisa 842 permintaan, dengan 35 detik hingga reset.
Angka-angka ini mengilustrasikan header. Angka tersebut bukan kuota yang dijamin. Baca nilai yang dikembalikan ke klien Anda.
| Field | Arti |
|---|---|
| Quoted name | Grup tempat kebijakan berlaku. |
q | Permintaan yang diizinkan per jendela. |
w | Panjang jendela dalam detik. |
r | Sisa permintaan. |
t | Detik hingga reset, bukan timestamp. |
Sebuah respons dapat membawa lebih dari satu kebijakan. Perhitungkan setiap kebijakan yang berlaku saat menjadwalkan permintaan berikutnya.
Apa yang dikembalikan oleh kegagalan pembatasan laju permintaan?
Batas API yang habis mengembalikan 429 Too Many Requests dengan Retry-After dalam detik. Header pembatasan laju permintaan mengidentifikasi grup yang habis. Sisa kuotanya adalah r=0.
Respons kesalahan mencakup field berikut:
{
"error": {
"type": "rate_limit_error",
"code": "E01003",
"name": "RateLimited"
}
}Cocokkan type atau code di handler Anda. Pesan yang dapat dibaca manusia dapat berubah tanpa mengubah tindakan pemulihan.
Bagaimana seharusnya klien saya menangani 429?
Tunggu selama Retry-After, lalu coba lagi dengan kebijakan backoff terbatas. Pertahankan kunci idempotensi yang sama saat mengulangi operasi tulis yang sama.
Koordinasikan worker yang menggunakan anggaran grup yang sama. Respons terakhir sebuah worker tidak dapat memperhitungkan permintaan yang telah dikirim oleh worker lain sejak saat itu.
Perlambat laju saat sisa kuota menurun. Pertahankan jalur percobaan ulang untuk lalu lintas bersamaan. Pengaturan kecepatan mengurangi kegagalan tetapi tidak dapat menjamin bahwa tidak ada panggilan yang menerima 429.
SDK Bird menangani percobaan ulang 429 dan Retry-After. SDK tidak mengoordinasikan antrean bersama di semua proses Anda.
Jika kuota tetap terlalu rendah untuk beban kerja, hubungi Bird mengenai override. Membuat lebih banyak kunci tidak meningkatkan batas pengiriman tingkat organisasi.
Apakah permintaan yang dibatasi sudah melakukan pekerjaan?
Bird menolak permintaan yang dibatasi sebelum melakukan pekerjaan yang diminta. Penolakan tersebut tidak menggunakan kunci idempotensinya. Coba lagi dengan kunci yang sama setelah menunggu.
Limiter meloloskan permintaan jika tidak dapat mengevaluasi batas. Masalah dalam mengevaluasi kuota tidak dengan sendirinya menghasilkan 429.
Pertahankan penanganan idempotensi untuk kegagalan lain juga. Kesalahan server atau respons yang hilang dapat terjadi setelah operasi tulis dimulai.
Singkatnya
Baca kuota dari respons.
Batas yang berlaku bergantung pada grup, paket, dan override yang ada. Angka tetap bisa menjadi tidak akurat.
Koordinasikan pengirim yang berbagi kuota.
Batas pengiriman berlaku di seluruh organisasi, sehingga kunci terpisah tidak membuat anggaran pengiriman terpisah.
Tunggu sebelum mencoba lagi 429.
Retry-Aftermemberikan jeda dalam detik. Batasi jumlah percobaan ulang Anda. Pertahankan kunci idempotensi untuk operasi tulis yang sama.Perlakukan header sebagai state bersama.
Sisa permintaan dapat digunakan oleh worker lain, sehingga pengaturan kecepatan mengurangi kegagalan pembatasan laju permintaan tanpa menghilangkannya.