IOSOR

IOSOR Tudás

API sebességkorlátok pilóttól productionig: backoff prepaid égetése nélkül

Pilóta- és production korlátok, exponenciális backoff, idempotencia, sandbox versus production kulcsok és határolt webhook-replay ablak — hogy a retryk ne ürítsék a prepaid tárcát.

A 429 nem meghívó, hogy a send API-t verjük, amíg valami átmegy. Prepaiden a retrystorm tárcaesemény: dupla OTP, egymásra rakott alerték, párosítatlan ledger sorok. A korlátok azért vannak, hogy a termék, az engineering és a finance egy plafont osszon. Pilóttól productionig nem „vedd le a capet” — szerződéses korlátok, idempotenciát tisztelő backoff, külön sandbox és production kulcsok, és webhook-replay ablak, amely nem debitál kétszer. Lásd idempotencia, újrapróbálás és pénz.

Az IOSOR white-label prepaid: autentikált hívások, korrelálható debiték, client-safe hibák, amelyek soha nem öntenek idegen márka payloadot.

A korlátok védik a prepaidet, nem bug

A korlátok azt határolják, hány elfogadott intent üti a tárcát ablakonként — nem hogy hány TCP próbát csinált a balancer. Dokumentálja az ablakot (kulcsonként, fiókonként, célosztályonként), a kódot és a Retry-Aftert. Az a kliens, aki a 429-et „próbáld erősebben”-ként olvassa, a finance ellen fut. Exportálja a korlát-elutasításokat a sikeres debiték mellé.

Backoff második debit nélkül: korlátok idempotenciával

Az exponenciális backoff idempotencia kulcs nélkül remegő hálóból két OTP-t csinál. A kulcs üzleti intentenként egyedi, nem TCP próbánként, és ugyanazt az accepted eredményt adja vissza tiszta TTL-en belül. A user resend másik termékakció saját korláttal. A low-balance stop érvényes: a retry nem lyukaszthat át üres tárcát.

Pilóta korlátok versus production korlátok

A pilóta kulcsoknak szorosabbnak kell lenniük: alacsony volumen, gyors láthatóság, olcsó hibák. A production korlátok szerződésesek azokra a folyosókra, amelyeket tényleg futtatnak. A plafon emelése tulajdonossal rendelkező fiókváltozás. A load tesztek sandbox kulcsokra valók; production kulcs soakban prepaidet éget. Ne ígérjen production QPS-t, amíg a katalógusfolyosó in setup.

Kulcsok és webhook-replay ugyanabban a cutoverben

A send korlátok nem mentenek, ha a webhook consumer kétszer dolgozza fel a DLR-t. Cutover: fagyassza a sandbox forgalmat, adjon production kulcsokat, irányítsa a webhookokat production consumerekre, ellenőrizze az aláírásokat, határolja a replay ablakot, aztán egy valódi intent. A 02:00-kor megismételt callback no-op legyen, ne második debit. Külön titkok; soha ne illessze ticketbe.

Piros zászlók

  • „Retry 200-ig” idempotencia kulcs nélkül
  • 429 mint lágy 200
  • Production kulcs load tesztben vagy sandbox webhook URL productionben
  • Replay ablak hetekben, vagy aláíratlan callbackek „a pilótának”
  • User resend összekeverve az auto-retry költségkerettel
  • Ügyfélhibák, amelyek nyers upstream kódokat öntenek

Kezdés IOSOR-ral

Írja le a limitablakot — kulcsonként, számlánként vagy célosztályonként — és a Retry-Aftert, amelyet tiszteletben tart. Kényszerítsen egy 429-et, hátráljon, majd ugyanazzal az Idempotency-Key-jel próbálja újra ugyanazt a szándékot. A ledger egy terhelést mutasson. Cserélje a sandbox kulcsot productionre, mielőtt plafont emel.

IOSOR összegzés

Tegye: a 429-et Retry-Afteres szünetnek tekintse, ne puha sikernek. Minden hátrálást az eredeti kulcshoz kössön, hogy a prepaid egy elfogadott szándékot lásson.

Ne tegye: production limiteket terhelésteszt-kulcson emelni, vagy kulcs nélkül 200-ig verni, amíg a tárca extra használatnak tűnik.

Hasznos volt ez az útmutató?

Kapcsolódó útmutatók