IOSOR

IOSOR Kunnskap

API-hastighetsgrenser fra pilot til produksjon: backoff uten å brenne prepaid

Pilot- og produksjonsgrenser, eksponentiell backoff, idempotens, sandbox- versus produksjonsnøkler og et begrenset webhook-replayvindu — så retries ikke tømmer prepaid-lommeboken.

En 429 er ikke en invitasjon til å hamre send-API-et til noe går gjennom. På prepaid er en retrystorm en lommebokhendelse: dobbel OTP, stablede alerts, umatchede ledgerlinjer. Grenser finnes så produkt, engineering og finance deler ett tak. Fra pilot til produksjon er ikke «fjern cap» — kontrakterte grenser, backoff som ærer idempotens, adskilte sandbox- og produksjonsnøkler, og et webhook-replayvindu som ikke dobbeltdebiterer. Se idempotens, nytt forsøk og penger.

IOSOR er white-label prepaid: autentiserte kall, korrelerbare debiteringer, clientsikre feil som aldri dumper fremmede merkeladninger. live / in setup er uavhengig av hvor hardt dere retrier — en korridor in setup blir ikke Live fordi klienten loopet. Nær USD 1,000+ månedlig bruk går retrybudsjetter og nøkkelcutover inn i kommersiell gjennomgang. Hold overgang fra sandbox til produksjon og webhook-signatur og replayvindu i samme runbook.

Grenser beskytter prepaid, det er ikke en feil

Grenser begrenser hvor mange aksepterte intents som treffer lommeboken per vindu — ikke hvor mange TCP-forsøk balanceren gjorde. Dokumenter vindu (per nøkkel, konto, destinasjonsklasse), kode og Retry-After. En klient som leser 429 som «prøv hardere» løper mot finance. Eksporter grenseavslag ved siden av vellykkede debiteringer. Katalog live stopper fortsatt ved det publiserte taket; in setup er ikke en ubegrenset sandbox.

Signal Engineering Lommebok
429 / Retry-After Backoff, ær vinduet Null ekstra debitering for samme intent
5xx / timeout Retry i budsjett med samme idempotensnøkkel Én debitering hvis første forsøk landet
4xx business-avslag Ikke blind retry Ingen debitering, eller navngitt avslagslinje

Backoff uten annen debitering: grenser med idempotens

Eksponentiell backoff uten idempotensnøkkel gjør et flimrende nett til to OTP-er. Nøkkelen er unik per forretningsintent, ikke per TCP-forsøk, og returnerer samme aksepterte resultat innenfor en klar TTL. Brukergjensending er en annen produkthandling med egen grense. Low-balance-stop gjelder: en retry må ikke gjennomhulle en tom lommebok.

Pilotgrenser versus produksjonsgrenser

Pilotnøkler skal være strammere: lavt volum, rask synlighet, billige feil. Produksjonsgrenser er kontraktert for korridorer dere faktisk kjører. Å heve et tak er en kontoendring med eier. Loadtester hører hjemme på sandboxnøkler; en produksjonsnøkkel i et soak brenner prepaid. Lov ikke produksjons-QPS mens katalogkorridoren er in setup.

Nøkler og webhook-replay i samme cutover

Send-grenser redder dere ikke hvis webhook-konsumenten behandler DLR dobbelt. Cutover: frys sandboxtrafikk, utsted produksjonsnøkler, pek webhooks mot produksjonskonsumenter, verifiser signaturer, begrens replayvinduet, deretter én ekte intent. Et gjentatt callback kl. 02:00 skal være no-op, ikke en annen debitering. Adskilte secrets; lim dem aldri inn i en sak.

Røde flagg

  • «Retry til 200» uten idempotensnøkkel
  • 429 som myk 200
  • Produksjonsnøkkel i en loadtest eller sandbox-webhook-URL i produksjon
  • Replayvindu målt i uker, eller usignerte callbacks «for piloten»
  • Brukergjensending blandet inn i auto-retrybudsjettet
  • Klientfeil som dumper rå upstreamkoder

Start med IOSOR

Skriv ned grensevinduet — per nøkkel, konto eller destinasjonsklasse — og Retry-After dere vil hedre. Tving en 429, trekk dere, og prøv samme intensjon igjen med samme Idempotency-Key. Ledgers skal vise én debet. Bytt sandbox-nøkkelen mot production-nøkkelen før dere løfter et tak.

IOSOR takeaway

Gjør: behandle 429 som en pause med Retry-After, ikke som en myk suksess.

Var denne guiden nyttig?

Relaterte veiledninger