IOSOR

IOSOR Vedomosti

Prichádzajúce SMS webhooky: opakovania, poradie udalostí a idempotencia pri prijatí

Sprievodca vývojom pre B2B tímy spracúvajúce prichádzajúce SMS: prečo dochádza k opakovaniam, prečo poradie udalostí nie je zaručené, a ako urobiť váš prijímací endpoint idempotentným namiesto duplikovania konverzácií a spracovania STOP.

Každý spracovateľ prichádzajúcich správ nakoniec narazí na rovnaké tri prekvapenia: rovnaký webhook sa spustí dvakrát, udalosť "delivered" príde po "failed", ktorú mala nahradiť, a odpoveď STOP od zákazníka sa spracuje dvakrát, pretože dva servery prijali rovnaké opakovanie. Nič z toho nie je chyba platformy, ktorá vám posiela webhook — je to normálne správanie akéhokoľvek systému doručovania "aspoň raz", a váš prijímací endpoint musí byť pre túto realitu postavený od prvého dňa.

IOSOR doručuje prichádzajúce SMS, kľúčové slová STOP/HELP a udalosti doručenia ako white-label predplatené webhooky — správanie opakovania a poradia opísané nižšie je to, čo by mala predpokladať akákoľvek serióznu B2B integrácia bez ohľadu na to, aká platforma za ňou stojí.

Prečo webhooky vôbec opakujú

Poskytovateľ webhooku nemôže s istotou vedieť, či váš endpoint spracoval doručenie. Váš server môže vrátiť 200 po commite do databázy, ktorá je potom vrátená späť; load balancer môže stratiť odpoveď na spiatočnej ceste, aj keď váš handler uspel; nasadenie môže reštartovať váš proces uprostred požiadavky.

Tri režimy zlyhania, pre ktoré musíte navrhovať

Režim zlyhania Čo sa stane Čo sa pokazí, ak to ignorujete
Duplicitné doručenie Rovnaké ID udalosti príde 2+ krát Dvakrát počítané odpovede, duplicitné spracovanie STOP, duplicitné vlákna konverzácie
Udalosti mimo poradia Udalosť s neskoršou časovou pečiatkou príde pred skoršou Stav "delivered" je prepísaný späť na "sent"
Čiastočné/nejednoznačné

Idempotencia: jedna vlastnosť, ktorá rieši všetky tri

Idempotentný prijímací endpoint produkuje rovnaký konečný stav bez ohľadu na to, koľkokrát je rovnaká udalosť doručená. Mechanizmus je jednoduchý a dobre pochopený: každá prichádzajúca udalosť nesie jedinečné ID udalosti; pred spracovaním kontrolujete, či ste toto ID už zaznamenali; ak áno, okamžite vrátite úspech bez opätovného spracovania. 1.

Poradie udalostí: prečo je "posledný zápis vyhráva" nebezpečné

Webhookové udalosti pre rovnakú správu nie sú zaručene doručené v poradí, v ktorom sa odohrali. Opakovanie skoršej udalosti "queued" môže prísť po neskoršej udalosti "delivered" kvôli sieťovému jitteru, frontovaniu na strane poskytovateľa, alebo vašej vlastnej skupine workerov spracúvajúcej požiadavky mimo poradia.

STOP, HELP a ďalšie prichádzajúce kľúčové slová vyžadujú rovnakú disciplínu

Prichádzajúce kľúčové slová kritické pre súlad si zaslúžia najprísnejšiu idempotenciu zo všetkých. Duplicitný STOP by nikdy nemal dvakrát zaznamenať udalosť odhlásenia ani odoslať dve potvrdzujúce odpovede. Duplicitný HELP by nikdy nemal spustiť dve samostatné podporné informačné správy na rovnaké číslo v rovnakej minúte.

Začnite s IOSOR

Súvisiace: slučky inbound auto-odpovedí · Vyrovnávacia pamäť pre prichádzajúce webhooky proti výkyvom latencie operátorov · rezervácia predplateného zostatku pred prvým odpísaním.

Zhrnutie IOSOR

Inbound webhooky robia retry. Idempotencia na príjme je jediná bezpečná odpoveď; poradie nie je sľub.

Robte: kľúčujte udalosť a ignorujte dvojča. Nerobte: last-write-wins na STOP ani dve strhnutia za tú istú udalosť.

Pomohol tento sprievodca?

Súvisiace návody