IOSOR Tieto

API-nopeusrajoitukset pilotista tuotantoon: backoff ilman prepaidin polttamista

Pilotti- ja tuotantorajat, eksponentiaalinen backoff, idempotenssi, sandbox- versus tuotantoavaimet ja rajattu webhook-replay-ikkuna — jotta retryt eivät tyhjennä prepaid-lompakkoa.

429 ei ole kutsu hakata send-API:ta kunnes jotain menee läpi. Prepaidissa retrymyrsky on lompakkotapahtuma: kaksois-OTP, pinotut alertit, yhteensopimattomat ledger-rivit. Rajat ovat olemassa, jotta tuote, engineering ja finance jakavat yhden katon. Pilotista tuotantoon ei ole «poista cap» — sovitut rajat, backoff joka kunnioittaa idempotenssia, erilliset sandbox- ja tuotantoavaimet sekä webhook-replay-ikkuna joka ei veloita kahdesti. Katso idempotenssi, uudelleenyritys ja raha.

IOSOR on white-label prepaid: autentikoidut kutsut, korreloitavat veloitukset, asiakasturvalliset virheet jotka eivät koskaan dumppaa vieraita merkkilatauksia.

Rajat suojaavat prepaidia, se ei ole bugi

Rajat rajoittavat kuinka monta hyväksyttyä intenttiä osuu lompakkoon ikkunaa kohden — ei kuinka monta TCP-yritystä balansoija teki. Dokumentoi ikkuna (per avain, tili, kohdeluokka), koodi ja Retry-After. Asiakas joka lukee 429:n «yritä kovemmin» juoksee financea vastaan. Vie raja-hylkäykset onnistuneiden veloitusten viereen.

Backoff ilman toista veloitusta: rajat idempotenssilla

Eksponentiaalinen backoff ilman idempotenssiavainta tekee värisevästä verkosta kaksi OTP:tä. Avain on uniikki liiketoimintaintenttiä kohden, ei TCP-yritystä kohden, ja palauttaa saman hyväksytyn tuloksen selkeän TTL:n sisällä. Käyttäjän uudelleenlähetys on toinen tuoteaktio omalla rajallaan. Low-balance-stop pätee: retry ei saa lävistää tyhjää lompakkoa.

Pilottirajat versus tuotantorajat

Pilottiavaimien tulee olla tiukempia: matala volyymi, nopea näkyvyys, halvat virheet. Tuotantorajat on sovittu käytäville joita oikeasti ajatte. Katon nosto on tilimuutos omistajalla. Kuormitustestit kuuluvat sandbox-avaimille; tuotantoavain soakissa polttaa prepaidin. Älä lupaa tuotanto-QPS:ää kun katalogikäytävä on in setup.

Avaimet ja webhook-replay samassa cutoverissa

Send-rajat eivät pelasta jos webhook-kuluttaja käsittelee DLR:n kahdesti. Cutover: jäädytä sandbox-liikenne, myönnä tuotantoavaimet, osoita webhookit tuotantokuluttajiin, tarkista allekirjoitukset, rajaa replay-ikkuna, sitten yksi aito intentti. Toistettu callback klo 02:00 pitää olla no-op, ei toinen veloitus. Erilliset salaisuudet; älä koskaan liitä niitä tikettiin.

Punaiset liput

  • «Retry kunnes 200» ilman idempotenssiavainta
  • 429 pehmeänä 200:na
  • Tuotantoavain kuormitustestissä tai sandbox-webhook-URL tuotannossa
  • Replay-ikkuna viikoissa, tai allekirjoittamattomat callbackit «pilotille»
  • Käyttäjän uudelleenlähetys sekoitettuna auto-retrybudjettiin
  • Asiakasvirheet jotka dumppaavat raakoja upstream-koodeja

Aloita IOSORILLA

Kirjoita rajaikkuna — avainta, tiliä tai kohdeluokkaa kohti — ja Retry-After, jota kunnioitatte. Pakota 429, väisty, ja yritä samaa aikomusta uudelleen samalla Idempotency-Keyllä. Ledgerissä saa näkyä yksi veloitus. Vaihda sandbox-avain production-avaimeen ennen kuin nostatte kattoa.

IOSOR-yhteenveto

Tee: kohtele 429:ää Retry-After-taukona, ei pehmeänä onnistumisena. Liitä jokaiseen väistöön alkuperäinen avain, jotta prepaid näkee yhden hyväksytyn aikomuksen.

Älä: nosta production-rajoja kuormitustestiavaimella äläkä hakkaa 200:aan ilman avainta, kunnes lompakko näyttää lisäkäytöltä.

Oliko tästä oppaasta apua?

Aiheeseen liittyvät oppaat