IOSOR

IOSOR Panduan

Batas API dari percontohan ke produksi: backoff tanpa membakar prepaid

Batas percontohan dan produksi, backoff eksponensial, idempotensi, kunci sandbox versus produksi, dan jendela replay webhook terbatas — agar retry tidak mengosongkan dompet prepaid.

429 bukan undangan memukul API kirim sampai sesuatu lolos. Pada prepaid, badai retry adalah peristiwa dompet: OTP ganda, peringatan bertumpuk, baris ledger tak berpasangan. Batas ada agar produk, rekayasa, dan keuangan berbagi satu plafon. Dari percontohan ke produksi bukan «lepas cap» — batas terkontrak, backoff yang menghormati idempotensi, kunci sandbox dan produksi terpisah, dan jendela replay webhook yang tidak debit ganda. Lihat idempotensi, coba ulang, dan uang.

IOSOR adalah prepaid white-label: panggilan terautentikasi, debit yang dapat dikorelasikan, kesalahan aman klien yang tidak pernah menumpahkan muatan merek asing. live / in setup independen dari seberapa keras Anda retry — koridor in setup tidak menjadi Live karena klien berputar. Dekat USD 1,000+ pemakaian bulanan, anggaran retry dan cutover kunci masuk tinjauan komersial. Simpan cutover sandbox ke produksi dan tanda tangan webhook dan jendela replay dalam runbook yang sama.

Batas melindungi prepaid, bukan bug

Batas membatasi berapa intent diterima yang menghantam dompet per jendela — bukan berapa percobaan TCP balancer. Dokumentasikan jendela (per kunci, akun, kelas tujuan), kode, dan Retry-After. Klien yang membaca 429 sebagai «coba lebih keras» berlari melawan keuangan. Ekspor penolakan batas di samping debit sukses. Katalog live tetap berhenti di plafon terbit; in setup bukan sandbox tak terbatas.

Sinyal Rekayasa Dompet
429 / Retry-After Backoff, hormati jendela Nol debit ekstra untuk intent yang sama
5xx / timeout Retry dalam anggaran dengan kunci idempotensi yang sama Satu debit jika percobaan pertama mendarat
4xx tolak bisnis Jangan retry buta Tanpa debit, atau baris tolak bernama

Backoff tanpa debit kedua: batas dengan idempotensi

Backoff eksponensial tanpa kunci idempotensi adalah bagaimana jaringan goyah menjadi dua OTP. Kunci unik per intent bisnis, bukan per percobaan TCP, dan mengembalikan hasil diterima yang sama dalam TTL jelas. Kirim ulang pengguna adalah tindakan produk lain dengan batas sendiri. Stop saldo rendah berlaku: retry tidak boleh menembus dompet kosong.

Batas percontohan versus produksi

Kunci percontohan harus lebih ketat: volume rendah, visibilitas cepat, kesalahan murah. Batas produksi dikontrak untuk koridor yang benar-benar Anda jalankan. Menaikkan plafon adalah perubahan akun dengan pemilik. Uji beban milik kunci sandbox; kunci produksi dalam soak membakar prepaid. Jangan janjikan QPS produksi sementara koridor katalog in setup.

Kunci dan replay webhook dalam cutover yang sama

Batas kirim tidak menyelamatkan jika konsumen webhook memproses DLR dua kali. Cutover: bekukan lalu lintas sandbox, terbitkan kunci produksi, arahkan webhook ke konsumen produksi, verifikasi tanda tangan, batasi jendela replay, lalu satu intent nyata. Callback diulang pukul 02:00 harus no-op, bukan debit kedua. Rahasia terpisah; jangan tempel ke tiket.

Bendera merah

  • «Retry sampai 200» tanpa kunci idempotensi
  • 429 sebagai 200 lembut
  • Kunci produksi dalam uji beban atau URL webhook sandbox di produksi
  • Jendela replay diukur minggu, atau callback tak bertanda «untuk percontohan»
  • Kirim ulang pengguna tercampur anggaran auto-retry
  • Kesalahan klien menumpahkan kode mentah hulu

Mulai dengan IOSOR

Tulis jendela batas — per kunci, akun, atau kelas tujuan — dan Retry-After yang akan Anda hormati. Paksa 429, mundur, lalu coba lagi niat yang sama dengan Idempotency-Key yang sama. Ledger harus menunjukkan satu debit. Ganti kunci sandbox dengan kunci production sebelum menaikkan plafon.

Intisari IOSOR

Lakukan: anggap 429 sebagai jeda ber-Retry-After, bukan sukses lunak.

Apakah panduan ini membantu?

Panduan terkait