IOSOR Wiedza

Limity API od pilota do produkcji: backoff bez palenia prepaid

Limity pilota i produkcji, wykładniczy backoff, idempotencja, klucze sandbox versus produkcja i ograniczona ramka replay webhook — żeby retry nie opróżniały portfela prepaid.

429 nie zaprasza do młotkowania send API, aż coś przejdzie. Na prepaid burza retry to zdarzenie portfela: podwójne OTP, stos alertów, niesparowane wiersze ledger. Limity istnieją, by produkt, engineering i finanse dzieliły jeden sufit. Od pilota do produkcji to nie «zdjąć cap» — limity kontraktowe, backoff szanujący idempotencję, osobne klucze sandbox i produkcji oraz ramka replay webhook, która nie podwójnie debituje. Zobaczcie idempotencja, ponowienia i pieniądze.

IOSOR to prepaid white-label: uwierzytelnione wywołania, korelowalne debity, błędy bezpieczne dla klienta, które nigdy nie wylewają ładunków obcej marki. live / in setup jest niezależne od tego, jak twardo retrujecie — korytarz in setup nie staje się Live, bo klient zapętlił. Koło USD 1,000+ miesięcznego użycia budżety retry i cutover kluczy wchodzą w przegląd komercyjny. Trzymajcie przejście z sandbox na produkcję i podpis webhooka i okno replay w tym samym runbooku.

Limity chronią prepaid, to nie bug

Limity ograniczają, ile przyjętych intent trafia w portfel na okno — nie ile prób TCP zrobił balancer. Udokumentujcie okno (na klucz, konto, klasę destynacji), kod i Retry-After. Klient, który czyta 429 jako «próbuj mocniej», biegnie przeciw finansom. Eksportujcie odrzucenia limitu obok udanych debitów. Katalog live i tak staje na opublikowanym suficie; in setup nie jest nieograniczonym sandboxem.

Sygnał Engineering Portfel
429 / Retry-After Backoff, honorować okno Zero extra debitu na ten sam intent
5xx / timeout Retry w budżecie z tym samym kluczem idempotencji Jeden debit, jeśli pierwsza próba wylądowała
4xx odrzucenie biznesowe Nie retrujcie na ślepo Brak debitu lub nazwany wiersz odrzucenia

Backoff bez drugiego debitu: limity z idempotencją

Wykładniczy backoff bez klucza idempotencji to jak drżąca sieć staje się dwoma OTP. Klucz jest unikalny na intent biznesowy, nie na próbę TCP, i zwraca ten sam przyjęty wynik w jasnym TTL. Resend użytkownika to inna akcja produktu z własnym limitem. Stop niskiego salda działa: retry nie może przebić pustego portfela.

Limity pilota versus produkcja

Klucze pilota powinny być ciaśniejsze: niski wolumen, szybka widoczność, tanie błędy. Limity produkcji są kontraktowe dla korytarzy, które naprawdę odpalacie. Podniesienie sufitu to zmiana konta z właścicielem. Testy obciążenia należą do kluczy sandbox; klucz produkcji w soak pali prepaid. Nie obiecujcie QPS produkcji, póki korytarz katalogu jest in setup.

Klucze i replay webhook w tym samym cutover

Limity send nie uratują, jeśli consumer webhook dwa razy przetworzy DLR. Cutover: zamrozić ruch sandbox, wydać klucze produkcji, skierować webhooki na consumery produkcji, zweryfikować podpisy, ograniczyć ramkę replay, potem jeden prawdziwy intent. Powtórzony callback o 02:00 ma być no-op, nie drugim debitem. Osobne sekrety; nigdy nie wklejajcie ich w zgłoszenie.

Czerwone flagi

  • «Retry do 200» bez klucza idempotencji
  • 429 jako miękkie 200
  • Klucz produkcji w teście obciążenia lub URL webhook sandbox w produkcji
  • Ramka replay w tygodniach lub niepodpisane callbacki «dla pilota»
  • Resend użytkownika zmieszany z budżetem auto-retry
  • Błędy klienta wylewające surowe kody z góry

Start z IOSOR

Zapiszcie okno limitu — na klucz, konto lub klasę destynacji — oraz Retry-After, które będziecie honorować. Wymuście 429, zróbcie backoff i powtórzcie tę samą intencję tym samym Idempotency-Key. Ledger musi pokazać jeden debit. Zamieńcie klucz sandbox na production, zanim podniesiecie pułap.

Podsumowanie IOSOR

Róbcie: traktujcie 429 jako pauzę z Retry-After, nie jako miękki sukces.

Czy ten przewodnik był pomocny?

Powiązane przewodniki