Pembatasan laju untuk API publik: kuota praktis dan alur penguncian

Masalah apa yang sebenarnya diselesaikan pembatasan laju

Pembatasan laju untuk API publik bukan tentang menghukum pengguna. Ini adalah katup pengaman yang menjaga layanan Anda tetap tersedia ketika lalu lintas menjadi aneh, entah itu karena niat jahat atau hanya bug di sisi klien.

"Penyalahgunaan" seringkali terlihat normal pada awalnya: scraper yang mengunjungi setiap endpoint untuk menyalin data, percobaan login bruteforce, token stuffing terhadap rute otentikasi, atau klien yang kehilangan kendali yang mengulangi permintaan yang sama dalam loop ketat setelah timeout. Kadang-kadang tidak ada yang menyerang Anda sama sekali — pembaruan aplikasi mobile mengirimkan aturan cache yang salah dan tiba-tiba setiap perangkat memanggil API Anda setiap detik.

Tugasnya sederhana: lindungi uptime dan kendalikan biaya tanpa memblokir pengguna nyata yang melakukan pekerjaan normal. Jika backend Anda dimeterai (compute, database, email/SMS, panggilan AI), satu aktor bising bisa dengan cepat menjadi tagihan yang besar.

Pembatasan laju sendiri juga tidak cukup. Tanpa monitoring dan respons kesalahan yang jelas, Anda mendapatkan kegagalan diam-diam, pelanggan bingung, dan tiket dukungan yang terdengar seperti "API Anda turun" padahal sebenarnya sedang diturunkan kecepatannya.

Garis pengaman lengkap biasanya memiliki beberapa bagian terpisah:

• Rate limits: batas jendela pendek (per detik/menit) yang menghentikan lonjakan.
• Quotas: alokasi jangka lebih panjang (per hari/bulan) yang menjaga penggunaan tetap dapat diprediksi.
• Lockouts: pemblokiran sementara untuk pola yang jelas-jelas menyalahgunakan.
• Exceptions: allowlist untuk integrasi tepercaya, alat internal, atau pelanggan VIP.

Jika Anda membangun backend API pada platform seperti AppMaster, aturan ini tetap penting. Bahkan dengan kode yang bersih dan dihasilkan ulang, Anda akan menginginkan default protektif agar satu klien bermasalah tidak membawa seluruh layanan Anda.

Istilah kunci: rate limits, quotas, throttling, dan lockouts

Istilah-istilah ini sering tercampur, tetapi mereka menyelesaikan masalah berbeda dan terasa berbeda bagi pengguna.

Rate limit, quota, dan concurrency: apa artinya masing-masing

Sebuah rate limit adalah batas kecepatan: berapa banyak permintaan yang bisa dibuat klien dalam jendela pendek (per detik, per menit). Quota adalah anggaran: total penggunaan dalam periode lebih lama (per hari, per bulan). Concurrency limit membatasi berapa banyak permintaan yang dapat diproses sekaligus, berguna untuk endpoint mahal meskipun laju permintaan terlihat normal.

Di mana Anda menempelkan batas itu penting:

• Per IP: sederhana, tapi menghukum jaringan bersama (kantor, sekolah, operator seluler).
• Per user: bagus untuk aplikasi dengan login, tapi bergantung pada identitas yang andal.
• Per API key: umum untuk API publik, kepemilikan jelas dan mudah untuk dikomunikasikan.
• Per endpoint: berguna saat satu rute jauh lebih berat daripada yang lain.

Throttling vs blocking, dan peran lockouts

Soft throttling memperlambat klien (penundaan, kapasitas burst lebih kecil) sehingga mereka dapat pulih tanpa merusak alur kerja. Hard blocking menolak permintaan segera, biasanya dengan HTTP 429 (Terlalu Banyak Permintaan).

Sebuah lockout lebih kuat daripada 429 biasa. 429 mengatakan "coba lagi sebentar." Lockout mengatakan "berhenti sampai kondisi terpenuhi," seperti masa pendinginan, peninjauan manual, atau reset kunci. Gunakan lockout untuk sinyal penyalahgunaan yang jelas (credential stuffing, scraping agresif, otentikasi tidak valid berulang), bukan untuk lonjakan lalu lintas normal.

Jika Anda membangun API dengan alat seperti AppMaster, perlakukan ini sebagai kontrol terpisah: batas jendela pendek untuk burst, kuota lebih lama untuk biaya, dan lockout hanya untuk perilaku buruk berulang.

Memilih batas praktis tanpa menebak secara liar

Batas yang baik dimulai dengan satu tujuan: melindungi backend sambil membiarkan pengguna normal menyelesaikan pekerjaannya. Anda tidak perlu angka sempurna pada hari pertama. Anda membutuhkan baseline aman dan cara untuk menyesuaikannya.

Titik awal sederhana adalah batas per-API-key yang sesuai dengan jenis API Anda:

• Lalu lintas rendah: 60–300 permintaan per menit per kunci
• Lalu lintas sedang: 600–1.500 permintaan per menit per kunci
• Lalu lintas tinggi: 3.000–10.000 permintaan per menit per kunci

Kemudian pisahkan batas berdasarkan tipe endpoint. Read biasanya lebih murah dan bisa mendapat batas lebih tinggi. Write mengubah data, sering memicu logika ekstra, dan layak mendapat batas lebih ketat. Pola umum adalah sekitar 1.000/menit untuk rute GET tetapi 100–300/menit untuk POST/PUT/DELETE.

Juga identifikasi endpoint yang mahal dan perlakukan secara terpisah. Pencarian, pembuatan laporan, ekspor, unggahan file, dan apa pun yang menyentuh banyak tabel atau menjalankan logika bisnis berat harus memiliki bucket lebih kecil meskipun sisa API longgar. Jika backend Anda menggunakan alur kerja visual (misalnya Business Process flows), setiap langkah tambahan adalah kerja nyata yang berlipat saat beban naik.

Rencanakan untuk burst dengan dua jendela: jendela pendek untuk menyerap lonjakan cepat, plus jendela lebih panjang yang menjaga penggunaan berkelanjutan tetap terkendali. Kombinasi umum adalah 10 detik ditambah 10 menit. Ini membantu pengguna nyata yang mengklik cepat, tanpa memberi kesempatan scraper kecepatan tak terbatas.

Terakhir, tentukan apa yang terjadi ketika klien melampaui batas. Kebanyakan API publik mengembalikan HTTP 429 dengan waktu retry yang jelas. Jika pekerjaan aman untuk ditunda (seperti ekspor), pertimbangkan untuk mengantri daripada memblokir keras sehingga pengguna nyata tetap mendapatkan hasil.

Merancang kuota per-kunci yang terasa adil

Kuota per-kunci biasanya pendekatan paling adil karena mereka cocok dengan cara pelanggan menggunakan layanan: satu akun, satu API key, tanggung jawab jelas. Pembatasan berbasis IP masih berguna, tetapi sering menghukum pengguna yang tidak bersalah.

Alamat IP bersama adalah alasan utama. Satu kantor dapat keluar melalui satu IP publik, dan operator seluler dapat menempatkan ribuan perangkat di balik pool IP kecil. Jika Anda mengandalkan batas per-IP, satu pengguna bising dapat memperlambat semua orang. Kuota per-kunci menghindari itu, dan Anda dapat menjaga batas per-IP ringan sebagai cadangan untuk flood yang jelas.

Untuk membuat kuota terasa adil, kaitkan dengan tier pelanggan tanpa menjebak pengguna baru. Kunci gratis atau trial harus cukup untuk pengujian nyata, hanya bukan pada skala yang merugikan Anda. Pola sederhana adalah burst yang murah hati, laju berkelanjutan yang sedang, dan kuota harian yang sesuai dengan paket.

Kebijakan per-kunci yang tetap dapat diprediksi:

• Izinkan burst pendek (page loads, impor batch), lalu terapkan laju stabil.
• Tambahkan batas harian per kunci untuk membatasi scraping dan loop yang tak terkendali.
• Tingkatkan batas berdasarkan paket, tapi pertahankan struktur yang sama sehingga perilaku konsisten.
• Gunakan kap rendah untuk kunci yang baru dibuat sampai mereka membangun sejarah baik.
• Pertahankan batas per-IP kecil untuk menangkap flood yang jelas dan klien yang salah konfigurasi.

Untuk mencegah berbagi kunci dan pendaftaran otomatis, Anda tidak perlu pengawasan berat. Mulailah dengan pengecekan sederhana seperti perubahan geo yang tidak biasa, terlalu banyak IP berbeda per jam untuk satu kunci, atau banyak kunci baru dibuat dari sumber yang sama. Tandai dan perlambat terlebih dahulu; kunci hanya dikunci setelah sinyal berulang.

Lalu lintas anonim adalah area di mana batas lebih ketat masuk akal. Jika Anda menawarkan kunci trial, batasi kecepatannya ketat dan persyaratkan langkah verifikasi dasar sebelum menaikkan batas. Jika API Anda menyalakan formulir publik, pertimbangkan endpoint anonim terpisah dengan kuota sendiri sehingga sisa backend tetap terlindungi.

Jika Anda membangun API dengan platform seperti AppMaster, logika per-kunci lebih mudah dijaga konsistensinya karena auth, aturan bisnis, dan penanganan respons berada di satu tempat.

Respons dan header yang ramah klien (supaya pengguna bisa pulih)

Pembatasan laju hanya bekerja dalam jangka panjang jika klien dapat memahami apa yang terjadi dan apa yang harus dilakukan selanjutnya. Tujuannya adalah respons yang membosankan dan dapat diprediksi: kode status yang sama, field yang sama, arti yang sama di seluruh endpoint.

Saat klien mencapai batas, kembalikan HTTP 429 (Terlalu Banyak Permintaan) dengan pesan jelas dan waktu tunggu konkret. Kemenangan tercepat adalah menambahkan Retry-After, karena bahkan klien sederhana bisa menunggu dengan benar.

Satu set header kecil membuat batas menjadi mudah dimengerti. Pertahankan nama konsisten dan sertakan pada respons sukses (supaya klien bisa mengatur laju) dan respons 429 (supaya klien bisa pulih):

• Retry-After: detik untuk menunggu sebelum mencoba lagi
• X-RateLimit-Limit: jumlah permintaan yang diizinkan per jendela
• X-RateLimit-Remaining: permintaan tersisa dalam jendela saat ini
• X-RateLimit-Reset: kapan jendela direset (epoch seconds atau waktu ISO)
• X-RateLimit-Policy: teks singkat seperti "60 requests per 60s"

Buat body error se-struktural respons sukses Anda. Pola umum adalah objek error dengan code yang stabil, message yang ramah manusia, dan petunjuk pemulihan.

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry after 12 seconds.",
    "retry_after_seconds": 12,
    "limit": 60,
    "remaining": 0,
    "reset_at": "2026-01-25T12:34:56Z"
  }
}

Beri tahu klien bagaimana mundur ketika mereka melihat 429. Exponential backoff adalah default yang baik: tunggu 1s, lalu 2s, lalu 4s, dan batasi (misalnya, pada 30–60 detik). Juga jelaskan kapan harus berhenti melakukan retry.

Hindari kejutan dekat kuota. Ketika sebuah kunci mendekati batas (katakan 80–90% digunakan), sertakan field atau header peringatan supaya klien bisa melambat sebelum mereka mulai gagal. Ini penting ketika satu skrip dapat memanggil banyak rute secara cepat dan menghabiskan anggaran lebih cepat dari yang diharapkan.

Langkah demi langkah: rencana rollout sederhana untuk batas dan kuota

Rollout bekerja paling baik ketika Anda memperlakukan batas sebagai perilaku produk, bukan aturan firewall sekali jalan. Tujuan sama: lindungi backend sambil menjaga pelanggan normal tetap berjalan.

Mulailah dengan inventaris cepat. Daftar setiap endpoint, lalu tandai masing-masing berdasarkan biaya (CPU, pekerjaan database, panggilan pihak ketiga) dan risiko (login, reset password, pencarian, unggahan file). Itu mencegah Anda menerapkan satu batas tumpul di mana-mana.

Urutan rollout yang biasanya menghindari kejutan:

• Tandai endpoint menurut biaya dan risiko, dan putuskan mana yang perlu aturan lebih ketat (login, ekspor massal).
• Pilih kunci identitas dalam urutan prioritas: API key terlebih dahulu, lalu user id, dan IP hanya sebagai fallback.
• Tambahkan batas jendela pendek (per 10 detik atau per menit) untuk menghentikan burst dan skrip.
• Tambahkan kuota jendela lebih lama (per jam atau per hari) untuk membatasi penggunaan berkelanjutan.
• Tambahkan allowlist untuk sistem tepercaya dan alat internal agar operasi tidak terblokir.

Pertahankan rilis pertama konservatif. Lebih mudah melonggarkan nanti daripada membuka blokir pengguna yang marah.

Monitor dan sesuaikan, lalu versi kebijakan Anda. Lacak berapa banyak permintaan yang terkena batas, endpoint mana yang memicunya, dan berapa banyak kunci unik yang terpengaruh. Saat Anda mengubah angka, perlakukan itu seperti perubahan API: dokumentasikan, gulirkan bertahap, dan pisahkan aturan lama dan baru agar bisa rollback dengan cepat.

Jika Anda membangun API dengan AppMaster, rencanakan aturan ini bersamaan dengan endpoint dan logika bisnis sehingga batas cocok dengan biaya nyata tiap workflow.

Alur kerja lockout yang menghentikan penyalahgunaan tanpa drama

Lockout adalah sabuk pengaman. Mereka harus menghentikan penyalahgunaan yang jelas dengan cepat, tetapi tetap memberi pengguna normal jalur pemulihan yang jelas saat terjadi kesalahan.

Pendekatan tenang adalah hukuman progresif. Anggap klien mungkin salah konfigurasi, bukan berniat jahat, dan tingkatkan hanya jika pola yang sama terulang.

Tangga progresif sederhana

Gunakan serangkaian langkah kecil yang mudah dijelaskan dan diimplementasikan:

• Peringatkan: beri tahu klien mereka mendekati batas, dan kapan jendela direset.
• Perlambat: tambahkan penundaan singkat atau batas per-detik yang lebih ketat untuk kunci itu.
• Lockout sementara: blokir selama beberapa menit (bukan jam) dengan waktu buka kunci yang tepat.
• Lockout lebih lama: hanya setelah burst berulang di beberapa jendela.
• Peninjauan manual: untuk pola yang tampak disengaja atau terus kembali.

Memilih apa yang harus dikunci penting. Per API key biasanya paling adil karena menargetkan pemanggil, bukan semua orang di balik jaringan bersama. Per akun membantu ketika pengguna memutar kunci. Per IP dapat membantu lalu lintas anonim, tetapi menyebabkan false positives untuk NAT, kantor, dan operator seluler. Ketika penyalahgunaan serius, gabungkan sinyal (misalnya, kunci kunci dan minta pemeriksaan ekstra untuk IP itu), tetapi pertahankan radius dampak kecil.

Buat lockout berbasis waktu dengan aturan sederhana: "diblokir sampai 14:05 UTC" dan "reset setelah 30 menit perilaku baik." Hindari banned permanen untuk sistem otomatis. Klien yang error bisa loop dan menghabiskan batas dengan cepat, jadi rancang hukuman untuk memudar seiring waktu. Periode laju rendah yang berkelanjutan harus mengurangi tingkat penalti.

Jika Anda membangun API di AppMaster, tangga ini cocok dengan counter tersimpan plus Business Process yang memutuskan allow, slow, atau block dan menulis waktu buka kunci untuk kunci tersebut.

Untuk pelanggar berulang, pertahankan jalur peninjauan manual. Jangan berdebat dengan pengguna. Minta request ID, timestamp, dan nama API key, lalu putuskan berdasarkan bukti.

Kesalahan umum yang menyebabkan false positives

False positives terjadi ketika pertahanan Anda memblokir pengguna normal. Biasanya terjadi saat aturan terlalu sederhana untuk cara orang sebenarnya menggunakan API Anda.

Kesalahan klasik adalah satu batas global untuk semua hal. Jika Anda memperlakukan endpoint baca yang murah dan ekspor mahal sama, Anda akan either overprotect yang murah (mengganggu) atau underprotect yang mahal (berbahaya). Pisahkan batas menurut biaya endpoint dan buat jalur berat lebih ketat.

Pembatasan hanya berdasarkan IP adalah perangkap umum lainnya. Banyak pengguna nyata berbagi satu IP publik (kantor, sekolah, operator seluler). Satu pengguna berat dapat membuat semua orang terblokir, dan terlihat seperti outage acak. Utamakan batas per-API-key terlebih dahulu, lalu gunakan IP sebagai sinyal sekunder untuk penyalahgunaan yang jelas.

Kegagalan juga dapat menciptakan false positives. Jika store limiter Anda turun, "fail closed" bisa menurunkan seluruh API Anda. "Fail open" bisa mengundang lonjakan yang malah menjatuhkan backend. Pilih fallback yang jelas: pertahankan cap darurat kecil di edge, dan degradasi dengan anggun pada endpoint non-kritis.

Penanganan klien lebih penting daripada yang kebanyakan tim duga. Jika Anda mengembalikan 429 generik tanpa pesan jelas, pengguna akan mencoba ulang lebih keras dan memicu lebih banyak blok. Selalu kirim Retry-After, dan buat teks error spesifik ("Too many requests for this key. Try again in 30 seconds.").

Masalah yang paling bisa dihindari adalah kerahasiaan. Limit tersembunyi terasa seperti bug ketika pelanggan menghadapi beban produksi untuk pertama kalinya. Bagikan kebijakan sederhana dan pertahankan stabilitasnya.

Checklist cepat untuk menghindari false positives:

• Pisahkan batas untuk endpoint mahal vs murah
• Prioritaskan pembatasan berdasarkan API key, bukan hanya IP
• Perilaku yang didefinisikan ketika limiter tidak tersedia
• Respons 429 yang jelas dengan Retry-After
• Batas yang didokumentasikan dan dikomunikasikan sebelum penegakan

Jika Anda membangun API dengan alat seperti AppMaster, ini sering berarti menetapkan caps berbeda per endpoint dan mengembalikan payload error konsisten sehingga klien bisa mundur tanpa menebak.

Monitoring dan alerting yang benar-benar membantu

Pembatasan laju hanya bekerja jika Anda bisa melihat apa yang terjadi secara real time. Tujuannya bukan menangkap setiap lonjakan, tapi mendeteksi pola yang berubah menjadi outage atau pelanggan marah.

Mulailah dengan sekumpulan sinyal kecil yang menjelaskan volume dan niat:

• Permintaan per menit (secara keseluruhan dan per API key)
• Tingkat 429 (permintaan diturunkan) dan tingkat 5xx (nyeri backend)
• Ledakan 401/403 berulang (kunci salah, credential stuffing, klien salah konfigurasi)
• Endpoint teratas menurut volume dan biaya (query lambat, ekspor berat)
• Endpoint baru atau tak terduga yang muncul di top 10

Untuk memisahkan "lalu lintas buruk" dari "kami merilis sesuatu," tambahkan konteks ke dashboard: waktu deploy, perubahan feature flag, pengiriman marketing. Jika lalu lintas naik tepat setelah rilis dan campuran 429/5xx tetap sehat, biasanya itu pertumbuhan, bukan penyalahgunaan. Jika lonjakan terkonsentrasi pada satu kunci, satu rentang IP, atau satu endpoint mahal, perlakukan sebagai mencurigakan.

Alert harus membosankan. Gunakan ambang + cooldown supaya Anda tidak dipanggil setiap menit untuk event sama:

• Tingkat 429 di atas X% selama 10 menit, beri notifikasi sekali per jam
• 5xx di atas Y% selama 5 menit, segera page
• Satu kunci melebihi kuota Z% selama 15 menit, buka investigasi
• Ledakan 401/403 di atas N/min, tandai kemungkinan penyalahgunaan

Saat alert menyala, buat catatan insiden singkat: apa yang berubah, apa yang Anda lihat (kunci/endpoint teratas), dan apa yang Anda sesuaikan (limit, cache, blokir sementara). Seiring waktu, catatan itu menjadi playbook nyata Anda.

Contoh: Anda meluncurkan endpoint pencarian baru dan lalu lintas menggandakan. Jika sebagian besar panggilan menyentuh endpoint itu di banyak kunci, naikkan kuota per-kunci sedikit dan optimalkan endpoint. Jika satu kunci melakukan ekspor nonstop dan menaikkan latensi, batasi endpoint itu secara terpisah dan hubungi pemiliknya.

Checklist cepat: pemeriksaan kewarasan sebelum dan setelah peluncuran

Pengaturan yang baik terasa membosankan saat bekerja. Checklist ini menangkap masalah yang biasanya menyebabkan false positives atau meninggalkan celah jelas.

Sebelum Anda merilis endpoint baru

Jalankan pemeriksaan ini di staging dan lagi tepat setelah peluncuran:

• Identity: konfirmasi limiter menggunakan kunci yang tepat (API key pertama, lalu user atau IP sebagai fallback), dan bahwa kunci yang diputar tidak mewarisi penalti lama.
• Limits: tetapkan kuota default per-kunci, lalu sesuaikan berdasarkan biaya endpoint (baca murah vs tulis mahal) dan burst yang diharapkan.
• Responses: kembalikan status dan info pemulihan yang jelas (waktu retry, sisa anggaran, kode error stabil).
• Logs: catat siapa yang dibatasi (key/user/IP), rute mana, aturan apa yang memicu, dan request ID untuk dukungan.
• Bypass: pertahankan allowlist darurat untuk monitor dan integrasi tepercaya.

Jika Anda membangun di AppMaster, perlakukan setiap endpoint API baru sebagai keputusan tier-biaya: lookup sederhana bisa longgar, sementara apa pun yang memicu logika bisnis berat harus mulai lebih ketat.

Saat terjadi insiden (penyalahgunaan atau lonjakan mendadak)

Lindungi backend sambil membiarkan pengguna nyata pulih:

• Naikkan cap sementara hanya untuk rute yang paling tidak berisiko (seringkali baca) dan pantau tingkat error.
• Tambahkan allowlist singkat untuk pelanggan baik yang diketahui saat Anda menyelidik.
• Perketat rute yang berisiko secara spesifik daripada menurunkan batas global.
• Aktifkan identitas yang lebih kuat (wajibkan API key, kurangi ketergantungan pada IP) untuk menghindari memblokir jaringan bersama.
• Ambil sampel: kunci teratas, IP teratas, user agent, dan pola payload yang tepat.

Sebelum meningkatkan batas untuk pelanggan, periksa pola permintaan normal mereka, campuran endpoint, dan apakah mereka bisa batch atau menambahkan backoff. Juga pastikan mereka tidak berbagi satu kunci di banyak aplikasi.

Bulanan, tinjau: endpoint yang paling sering dibatasi, persentase lalu lintas yang terkena batas, route berbiaya tinggi baru, dan apakah kuota masih sesuai dengan penggunaan nyata.

Skenario contoh: melindungi API publik nyata tanpa merusak pengguna

Bayangkan Anda menjalankan API publik yang digunakan oleh dua aplikasi: portal pelanggan (lalu lintas tinggi, stabil) dan alat admin internal (lalu lintas rendah, tetapi tindakan kuat). Keduanya menggunakan API key, dan portal juga memiliki endpoint login untuk pengguna akhir.

Suatu sore, mitra mengirimkan integrasi bermasalah. Integrasi itu mulai mengulangi permintaan yang gagal dalam loop ketat, mengirim 200 permintaan per detik dari satu API key. Tanpa garis pengaman, satu kunci itu bisa mengusir semua pengguna lain.

Batas per-kunci membatasi radius ledakan. Kunci bermasalah mencapai cap per-menitnya, mendapat respons 429, dan pelanggan lain tetap bekerja. Anda mungkin juga punya batas terpisah, lebih rendah, untuk endpoint mahal (seperti ekspor) sehingga bahkan lalu lintas yang "diizinkan" tidak bisa membebani database.

Pada saat yang sama, percobaan brute-force login mulai menyerang endpoint auth. Alih-alih memblokir seluruh rentang IP (yang dapat memengaruhi pengguna nyata di balik NAT), Anda memperlambatnya lalu menguncinya berdasarkan perilaku: terlalu banyak percobaan gagal per akun ditambah per IP dalam jendela singkat. Penyerang mendapat penundaan yang semakin panjang, lalu lockout sementara.

Pelanggan nyata yang salah mengetik kata sandi beberapa kali masih bisa pulih karena respons Anda jelas dan dapat diprediksi:

• 429 dengan Retry-After sehingga klien tahu kapan mencoba lagi
• Lockout singkat (misalnya 10–15 menit), bukan banned permanen
• Pesan error konsisten yang tidak membocorkan apakah akun ada atau tidak

Untuk memastikan perbaikan, Anda mengamati beberapa metrik:

• Tingkat 429 per API key dan endpoint
• Tingkat kegagalan auth dan hitungan lockout
• Latensi P95 dan CPU database selama insiden
• Jumlah kunci unik yang terpengaruh (seharusnya kecil)

Inilah seperti apa pembatasan laju protektif ketika melindungi backend tanpa menghukum pengguna normal.

Langkah selanjutnya: buat kebijakan kecil dan iterasi

Anda tidak perlu model sempurna pada hari pertama. Mulailah dengan kebijakan kecil dan jelas lalu perbaiki saat Anda belajar bagaimana pengguna nyata berperilaku.

Versi pertama yang solid biasanya memiliki tiga bagian:

• Baseline per-kunci (permintaan per menit) yang mencakup sebagian besar endpoint
• Cap lebih ketat pada endpoint mahal (pencarian, ekspor, unggahan file, laporan kompleks)
• Respons 429 yang jelas dengan pesan singkat yang memberi tahu klien apa yang harus dilakukan selanjutnya

Tambahkan lockout hanya di tempat risiko penyalahgunaan tinggi dan niat mudah disimpulkan. Signup, login, reset password, dan pembuatan token adalah kandidat khas. Pertahankan lockout singkat pada awalnya (menit, bukan hari), dan utamakan friction progresif: perlambat, lalu blokir sementara, lalu minta pemeriksaan lebih kuat.

Tuliskan kebijakan itu dalam bahasa biasa sehingga dukungan dapat menjelaskannya tanpa bantuan engineering. Sertakan apa yang dibatasi (per API key, per IP, per akun), jendela reset, dan bagaimana pelanggan bisa pulih.

Jika Anda menerapkan ini saat membangun backend baru, AppMaster bisa menjadi pilihan praktis: Anda bisa membuat API, mendefinisikan workflow bisnis (termasuk counter dan keputusan lockout) secara visual, lalu deploy ke penyedia cloud atau ekspor source code yang dihasilkan ketika Anda membutuhkan kendali penuh.