IOSOR

IOSOR Teadmised

Saatmise API idempotentsus: duplikaadid, uuesti katsed ja raha

Arendaja juhend prepaid saatmise API-dele — idempotentsusvõtmed, turvalised uuesti katsed, duplikaatide vältimine ja ledgerile sõbralik korrelatsioon, et engineeringi vead ei muutuks finantsintsidentideks.

Timeout'id juhtuvad. Koormuse tasakaalustajad proovivad uuesti. Mobiilikliendid teevad double-tap'i. Ilma idempotentsuseta saab "saada üks kord" tootest topelt prepaid deebet ja dubleeritud OTP UX.

IOSOR ootab money-aware integratsioone: autentitud kutseid, korreleeritavaid deebeteid ja kliendivigu, mis ei viska kunagi võõraid brändipayload'e. Ligikaudu USD 1 000+ kuise platvormikasutuse juures pole duplikaadidistsipliin enam valikuline.

Miks duplikaatidest saavad rahaprobleemid

Rikkerežiim Kasutaja näeb Rahakott näeb
Kliendi timeout + pime uuesti katse Kaks OTP-d / kaks hoiatust Kaks deebetit
Mitteidempotentne webhook-töötleja Topelt kõrvalmõjud Segadus success'il
Kasutaja uuesti saatmine auto-retry peal Ärritunud kasutajad Kogunenud ühikud
Korrelatsioon puudub "Ebaõnnestus" piletid Sobimatud ledger read

Demod andestavad. Tootmise finance ei. Prepaid intensiivsuse juures saab pimedate uuesti katsete nädalavahetusest võrdlusprojekt, mitte logi allmärkus. Kujundage happy path ja timeout rada sama deebetireegliga.

Idempotentsusvõtmed, mis peavad uuesti katsetele vastu

Tõsine saatmisrada aktsepteerib kliendi genereeritud võtit, mis on unikaalne ärilise kavatsuse, mitte TCP katse kohta. See peab tagastama replay'l selges TTL aknas sama accepted tulemuse. See hoiab ära vaikimisi teise deebeti loomise samale kavatsusele. Logige võti message ID ja prepaid viite kõrvale.

Uuesti katsete eelarved vs kasutaja uuesti saatmine

Automaatsed uuesti katsed vajavad eelarvet: max katsed, backoff ja retryable veaklasside definitsioon. Kasutaja algatatud uuesti saatmine on teine tooteaktsioon oma piirangute ja prepaid kuludega. Nende kahe maailma segamine muudab ebastabiilse võrgu nädalavahetuse finantsintsidendiks.

Ostja / engineeringu kontrollnimekiri

  1. Dokumenteeritud idempotentsusvõtme semantika ja TTL.
  2. Replay test, mis tõestab ühte deebetit ühe kavatsuse kohta.
  3. Eraldi eelarve auto-retry ja user resend loogikale.
  4. Korrelatsiooni-ID-d üle request'i, sõnumi staatuse ja prepaid ledger'i.
  5. Staging, mis simuleerib reaalseid koridore — mock'id ei ole launch.
  6. Võtmete hügieen ja least privilege saatmise mandaatidele.
  7. 429 ja 503 koodide käsitlemine ilma algset kavatsuse võtit kaotamata.
  8. Automatiseeritud hoiatused kõrge duplikaatvõtmete tagasilükkamise määra kohta.

Punased lipud

  • "Retry'i kuni 200" ilma idempotentsusvõtmeid kasutamata.
  • Webhook-töötlejad, mis ei ole idempotentsed ja käivitavad kõrvalmõjud kaks korda.
  • Täis secret-võtmed või auth-tokenid logides või support-piletites.
  • Vead, mis tagastavad upstream brändi payload'e või stack trace'i lõppkasutajale.
  • Duplikaatvõtmete seire puudumine.

Alustage IOSOR-iga

Saatmiskonsoolis laske üks OTP või hoiatus kliendi loodud idempotentsusvõtmega. Sundige kliendi ajalõpp ja esitage sama päring võtme TTL sees. Avage prepaid-ledger: sellel kavatsusel peab olema üks deebet ja üks nähtav sõnum. Kaks rida tähendab, et võti ei jäänud korduskatsest ellu — parandage TTL ja töötleja enne, kui koridor jääb Live’iks.

IOSOR kokkuvõte

Tehke: käsitlege iga saatmist esmalt ledger-sündmusena. Võti on unikaalne ärilise kavatsuse, mitte TCP katse kohta. Automaatsel kordusel on eelarve; kasutaja uuesti saatmine on teine tootetoiming oma prepaid-kuluga.

Ärge: taguge 200-ni ilma võtmeta ega laske mitte-idempotentsel webhookil teist kõrvalmõju vermida. Kaks OTP-d ühe puudutuse kohta on rahaviga, mitte võrgulugu.

Kas see juhend oli kasulik?

Seotud juhendid