429 Too Many Requests — Siapa yang Membatasi Anda?

Siapa yang membatasi?

Kenali sumbernya sebelum mengubah apa pun. Responsnya sendiri biasanya sudah memberi tahu, asalkan Anda melihat header alih-alih hanya halamannya.

Retry-After: header yang memberi tahu langkah berikutnya

429 yang ditulis dengan benar menyertakan header Retry-After, dan itulah informasi paling berguna di seluruh respons.

Ia hadir dalam dua bentuk: jumlah detik yang harus ditunggu, atau tanggal HTTP untuk ditunggu sampai kapan. Apa pun bentuknya, itu adalah server yang memberi tahu persis kapan ia akan menerima permintaan lagi — jauh lebih baik daripada menebak.

Kalau Anda sedang menulis klien, baca dan patuhi. Mencoba lagi seketika setelah menerima 429 adalah perilaku yang membuat alamat IP diblokir sepenuhnya alih-alih sekadar diperlambat, karena dari sisi server itu tidak bisa dibedakan dari serangan.

Kalau Anda yang mengeluarkan 429, kirimkan header itu. Tanpa Retry-After, klien yang ditulis baik terpaksa menebak, dan klien yang ditulis buruk akan menghantam Anda terus-menerus.

Penyebab umum, dari yang paling sering

• Kode memanggil API dalam loop tanpa mengatur tempo. Mengiterasi beberapa ribu record lalu memanggil API satu per record akan menabrak hampir semua rate limit dalam hitungan detik.
• Tidak ada cache untuk panggilan berulang. Mengambil kurs atau data produk yang sama pada setiap pemuatan halaman berarti mengalikan jumlah permintaan dengan jumlah trafik.
• Proteksi bot salah menandai trafik yang sah. Cloudflare dan alat sejenis kadang menggolongkan alat monitoring, pembaca feed, atau crawler yang rajin tapi jujur sebagai penyalahgunaan.
• Berbagi alamat IP. Di shared hosting atau di balik NAT perusahaan, Anda mewarisi reputasi sekaligus jumlah permintaan semua orang yang memakai alamat itu.
• wp-cron atau polling serupa di situs ramai. WordPress memicu cron mengikuti jumlah tampilan halaman; di situs bertrafik tinggi itu bisa berarti ratusan permintaan internal per menit.
• Loop retry tanpa backoff. 429 pertama memicu percobaan ulang, yang menghasilkan 429 lagi, yang memicu percobaan lagi — mengubah pembatasan singkat menjadi blokir berkepanjangan.
• Endpoint login atau formulir sedang dibobol paksa. Di sini 429 sedang menjalankan tugasnya, dan tindakan yang benar adalah membiarkannya.

Kalau kode Anda yang dibatasi: mundur dengan benar

Ketika Anda berada di sisi klien, perilaku yang benar sudah punya standar jelas dan layak ditulis dengan baik sekali saja.

Gunakan exponential backoff dengan jitter. Tunggu 1 detik, lalu 2, lalu 4, lalu 8 — dan tambahkan sedikit nilai acak setiap kali. Bagian acaknya penting: tanpa itu, semua klien yang gagal bersamaan akan mencoba lagi bersamaan, menciptakan gelombang serempak yang membuat semuanya tetap dibatasi.

Patuhi Retry-After bila ada. Ia mengalahkan perhitungan backoff Anda sendiri, karena server lebih tahu daripada algoritma Anda.

Batasi jumlah percobaan ulang. Loop retry tanpa batas mengubah pembatasan sementara menjadi blokir permanen sekaligus menyembunyikan masalah aslinya dari Anda.

Cache seagresif mungkin. Permintaan termurah adalah yang tidak pernah dikirim. Data yang berubah tiap jam tidak perlu diambil ulang di setiap tampilan halaman, dan cache singkat sering menghapus masalah rate limit sepenuhnya.

Gunakan batch kalau API mendukung. Satu permintaan untuk seratus record lebih baik daripada seratus permintaan untuk satu record, karena sebagian besar API menghitung permintaan, bukan record.

Kalau pengunjung Anda yang kena 429

• Pastikan dulu itu server Anda atau CDN. Halaman errornya memberi tahu: halaman ber-branding dengan ray ID berarti CDN, halaman polos berarti server.
• Tinjau pola permintaan sebenarnya di access log sebelum melonggarkan apa pun. Kalau trafiknya memang menyalahgunakan, limitnya bekerja benar dan sebaiknya dibiarkan.
• Cari salah tandai pada bot baik. Googlebot, alat pemantau uptime, dan pembaca feed yang sah bisa tersangkut aturan yang terlalu ketat — dan membatasi Googlebot akan merugikan peringkat Anda.
• Periksa apakah situs Anda sendiri yang menghasilkan beban itu. Plugin yang mem-polling endpoint internal, atau cron yang salah konfigurasi, bisa menghabiskan kuota sebelum pengunjung asli datang.
• Aktifkan page cache sebelum menaikkan limit. Halaman yang sudah di-cache bahkan tidak menyentuh penghitungnya, jadi ini memperbaiki penyebab, bukan gejala.
• Atur limit per endpoint, bukan secara global. Endpoint login dan API layak dibatasi ketat; halaman konten statis biasanya tidak perlu dibatasi sama sekali.

Kenapa menaikkan limit biasanya langkah pertama yang keliru

Naluri saat melihat 429 adalah menaikkan ambangnya. Kadang itu benar, tapi lebih sering ia mengubah satu masalah menjadi masalah yang lebih buruk.

Rate limit ada untuk melindungi kapasitas yang terbatas. Menaikkan ambang tanpa menambah kapasitas berarti permintaan itu kini benar-benar sampai ke aplikasi, memakan worker dan memori, dan Anda menukar 429 yang rapi dengan situs lambat atau 503 — pengalaman yang lebih buruk dengan biaya lebih mahal.

Urutan yang lebih baik: cache dulu, agar sebagian besar permintaan tidak pernah menyentuh penghitung; perbaiki apa pun yang menghasilkan beban tak perlu; lalu kalau permintaan asli memang masih melampaui limit, naikkan sambil menambah kapasitas untuk melayaninya.

Pengecualiannya adalah limit yang sejak awal memang disetel terlalu rendah untuk trafik normal. Kalau access log menunjukkan pengunjung biasa menjelajah secara wajar tapi tetap kena limit, itu salah konfigurasi dan menaikkannya adalah solusi yang tepat.