Rate limit, 429, dan kenaikan tier
Diperbarui September 1, 2026 · pertama terbit September 1, 2026
Saat sebuah layanan mulai mengembalikan 429, refleksnya adalah memperlakukannya sebagai insiden ketersediaan: naikkan batas, naikkan tier, tambahkan retry, pulihkan throughput. Kadang itu memang benar. Tetapi itu juga mekanisme yang mengubah loop yang lepas kendali menjadi tagihan lima digit, karena satu-satunya hal yang menghentikannya baru saja dicabut.
Apa sebenarnya yang disampaikan 429
Artinya sistem mencoba membelanjakan lebih cepat daripada alokasinya. Itu terjadi karena dua alasan yang sangat berbeda, dan keduanya membutuhkan respons yang berlawanan. Pertumbuhan permintaan yang nyata — lebih banyak pengguna, peluncuran, puncak musiman — berarti batasnya memang terlalu rendah, dan menaikkannya menghasilkan pendapatan nyata. Perilaku lepas kendali — badai retry, agen yang berputar, backfill yang tidak dibatasi, suite tes yang diarahkan ke kunci produksi — berarti batasnya bekerja persis seperti seharusnya.
Keduanya tidak bisa dibedakan hanya dari tingkat error. Keduanya sangat mudah dibedakan jika Anda melihat biaya per unit kerja: pertumbuhan nyata menjaga rasio tetap kurang lebih konstan saat volume naik; loop yang lepas kendali merusak rasio itu, dengan belanja jauh lebih besar per tugas yang selesai dibanding kemarin. Rasio tunggal ini seharusnya menjadi gerbang untuk setiap kenaikan tier.
Retry memperburuk keadaan, diam-diam
Retry naif pada 429 tanpa exponential backoff dan jitter mengubah satu pelanggaran batas menjadi badai yang tersinkronisasi. Permintaan yang berhasil ditagih; banyak yang gagal pun mungkin sudah mengonsumsi pemrosesan input. Dan karena retry biasanya diimplementasikan di library klien, bukan di kode aplikasi, amplifikasi ini tidak muncul di dokumen desain fitur mana pun.
Gunakan batas secara sengaja
Atur batas Anda sendiri di bawah batas provider, per lingkungan dan per fitur, sehingga yang pertama rusak adalah batas Anda dan Anda yang mengendalikan apa yang terjadi berikutnya. Batasi ketat lingkungan non-produksi — build tes yang gagal itu murah, jalur pelanggan yang terbatasi tidak. Pasang alert pada rasio biaya per tugas, bukan hanya pada jumlah error. Dan saat Anda menaikkan tier, perlakukan itu sebagai keputusan belanja dengan pemilik yang jelas, karena memang itulah wujudnya.
Terkait
Terkait
Ingin menerapkannya pada stack Anda? Bawa tagihan penyedia, log gateway, dan alur kerja utama; kami akan memetakan pendorong biaya dan jalur penghematan. Pesan audit gratis →