IOSOR

IOSOR Teadmised

Sissetulevad SMS-webhookid: korduskatsed, sündmuste järjekord ja idempotentsus vastuvõtul

B2B juhend vastuvõtuteele: kuidas sissetulevad SMS-webhookid uuesti proovivad, miks järjekord pole garanteeritud ning kuidas idempotentsed handlerid kaitsevad ettemaksu-ops’i ja toe makrosid.

Väljuv SMS saab juhtpaneelid. Sissetulev on koht, kus STOP, HELP ja kliendivastused tegelikult maanduvad — ja kus naiivsed handlerid leiutavad topelttikette, topelt-rahakoti kõrvalmõjusid ning vastavuse kummitusi „me ei saanud kunagi STOPi“. Kui vastuvõtutee eeldab exactly-once järjestuses, kukute esimesel tõelisel katkestusel.

IOSOR pakib sissetuleva messagingu samasse white-label ettemaksu pinda nagu väljuva: kontrollitavad sündmused, brand-turvalised payloadid, ilma võõras ops-portaalis elamata vastusetormi sobitamiseks.

Miks webhook’id üldse teevad retry’t

Enamikel platvormidel lubavad sissetulevad webhookid at-least-once koos korduskatsetega, mitte maagilist exactly-once korda.

  • Sama loogilise sündmuse topelt-POST’e
  • Hilisi saabumisi pärast timeout’i
  • Aeg-ajalt out-of-order teise sündmusetüübi suhtes

Toote UX võib ikka tunduda korrastatuna, kui teie store rakendab deterministlikku merge’i — mitte kui loodate, et juhe ei värise kunagi.

Kolm tõrkerežiimi, mille jaoks peate disainima

Failure mode What happens What breaks if you ignore it
Duplicate delivery Same event ID arrives 2+ times Double-counted replies, doubled STOP, duplicate threads
Out-of-order events A later-timestamped event arrives first A delivered status regresses to sent
Partial/ambiguous failure You processed but the ack was lost The platform retries work you already did

Idempotentsus: omadus, mis parandab kõik kolm

Sissetulev pole vaba rahast ega ops’i kõrvalmõjudest:

  • Automaatvastused võivad debiteerida ettemaksu rahakotti
  • STOP käsitlemine peab summutama tulevased marketingi saadetised
  • Toe makrod, mis avavad tikette, ei tohi avada kolme tiketetti kolme POST’i peale

Idempotentse vastuvõtu handleri kontrollnimekiri:

Sündmuste järjekord: miks on „last write wins“ ohtlik

Levinud valed eeldused:

  1. STOP jõuab enne järgmist marketingi saadetist (race on olemas)
  2. Väljuv DLR jõuab enne sissetulevat vastust (sõltumatud teed)
  3. „First POST wins“ ilma kestva sündmusevõtmeta

Ehitage vastuvõtu ledger kestva event / message id järgi. Rakendage ärireegleid olekuüleminekutena ledgeril — mitte kui „käivita kõrvalmõju igal HTTP 200 teel“.

STOP, HELP ja teised inbound märksõnad vajavad sama distsipliini

Compliance-critical inbound keywords deserve the strictest idempotency. A duplicated STOP must never double-log an opt-out or send two confirmations. A duplicated HELP must never fire two help messages to the same number in the same minute. Route keyword processing through the same dedupe table as regular inbound messages.

Alustage IOSORiga

Seotud: sissetuleva autovastuse silmused · Sisenevate webhook'ide puhverdamine operaatori viivituste vastu IOSOR-is · ettemakstud saldo reserveerimine enne esimest debiteerimist.

IOSOR kokkuvõte

Inbound-webhookid proovivad uuesti. Idempotentsus vastuvõtul on ainus turvaline vastus; järjekord ei ole lubadus.

Tehke: võtistage sündmus ja eirake kaksikut. Ärge: last-write-wins STOP-il ega sama sündmuse debiteerimine kaks korda.

Kas see juhend oli kasulik?

Seotud juhendid