IOSOR

IOSOR Ghiduri

Limite de rată API de la pilot la producție: backoff fără a arde prepaid

Limite de pilot și producție, backoff exponențial, idempotență, chei sandbox versus producție și o fereastră limitată de replay webhook — ca retry-urile să nu golească portofelul prepaid.

Un 429 nu e invitație să ciocăniți API-ul de send până trece ceva. Pe prepaid, o furtună de retry e un eveniment de portofel: OTP dublu, alerte stivuite, rânduri de ledger nepereche. Limitele există ca produsul, engineering și finance să împartă un plafon. De la pilot la producție nu e „scoate cap-ul” — limite contractate, backoff care onorează idempotența, chei sandbox și producție separate, și o fereastră de replay webhook care nu debitează de două ori. Vedeți idempotență, reîncercări și bani.

IOSOR e prepaid white-label: apeluri autentificate, debite corelabile, erori client-safe care nu varsă niciodată payload-uri de brand străin.

Limitele protejează prepaid, nu e un bug

Limitele limitează câte intent-uri acceptate lovesc portofelul pe fereastră — nu câte încercări TCP a făcut balancerul. Documentați fereastra (pe cheie, cont, clasă de destinație), codul și Retry-After. Un client care citește 429 ca „încearcă mai tare” aleargă împotriva finance. Exportați respingerile de limită lângă debitele reușite.

Backoff fără al doilea debit: limite cu idempotență

Backoff-ul exponențial fără cheie de idempotență face dintr-o rețea tremurătoare două OTP. Cheia e unică pe intent de business, nu pe încercare TCP, și returnează același rezultat acceptat în TTL clar. User resend e altă acțiune de produs cu propria limită. Stop-ul pe sold scăzut se aplică: un retry nu trebuie să străpungă un portofel gol.

Limite de pilot versus producție

Cheile de pilot trebuie să fie mai strânse: volum mic, vizibilitate rapidă, erori ieftine. Limitele de producție sunt contractate pentru coridoarele pe care le rulați cu adevărat. Ridicarea unui plafon e o schimbare de cont cu owner. Testele de sarcină aparțin cheilor sandbox; o cheie de producție într-un soak arde prepaid. Nu promiteți QPS de producție cât timp coridorul de catalog e in setup.

Chei și replay webhook în același cutover

Limitele de send nu vă salvează dacă consumatorul de webhook procesează DLR de două ori. Cutover: înghețați traficul sandbox, emiteți chei de producție, îndreptați webhook-urile spre consumatorii de producție, verificați semnăturile, limitați fereastra de replay, apoi un intent real. Un callback repetat la 02:00 trebuie să fie no-op, nu un al doilea debit.

Steaguri roșii

  • „Retry până la 200” fără cheie de idempotență
  • 429 ca 200 moale
  • Cheie de producție într-un load test sau URL webhook sandbox în producție
  • Fereastră de replay măsurată în săptămâni, sau callback-uri nesemnate „pentru pilot”
  • User resend amestecat în bugetul de auto-retry
  • Erori către client care varsă coduri upstream brute

Începeți cu IOSOR

Notați fereastra de limită — pe cheie, cont sau clasă de destinație — și Retry-After pe care îl veți onora. Forțați un 429, reculați, apoi reîncercați aceeași intenție cu aceeași Idempotency-Key. Ledger-ul trebuie să arate un debit. Schimbați cheia sandbox cu cea production înainte să ridicați un plafon.

Rezumat IOSOR

Faceți: tratați 429 ca o pauză cu Retry-After, nu ca un succes moale. Cuplați fiecare backoff cu cheia originală ca prepaid să vadă o intenție acceptată.

Nu faceți: ridicați limite production pe o cheie de test de sarcină, nici nu ciocăniți până la 200 fără cheie până portofelul arată consum extra.

A fost util acest ghid?

Ghiduri conexe