IOSOR

IOSOR Znalosti

Webhooky příchozích SMS: opakování, pořadí událostí a idempotence při přijetí

Průvodce vývojem pro B2B týmy zpracovávající příchozí SMS: proč dochází k opakováním, proč pořadí událostí není zaručeno, a jak udělat váš přijímací endpoint idempotentní místo duplikování konverzací a zpracování STOP.

Každý zpracovatel příchozích zpráv nakonec narazí na stejné tři překvapení: stejný webhook se spustí dvakrát, událost "delivered" přijde po "failed", kterou měla nahradit, a odpověď STOP od zákazníka se zpracuje dvakrát, protože dva servery přijaly stejné opakování. Nic z toho není chyba platformy, která vám webhook posílá — je to normální chování jakéhokoli systému doručování "alespoň jednou", a váš přijímací endpoint musí být pro tuto realitu postaven od prvního dne.

IOSOR doručuje příchozí SMS, klíčová slova STOP/HELP a události doručení jako white-label předplacené webhooky — chování opakování a pořadí popsané níže je to, co by měla předpokládat jakákoli seriózní B2B integrace bez ohledu na to, jaká platforma za ní stojí.

Proč webhooky vůbec opakují

Poskytovatel webhooku nemůže s jistotou vědět, že váš endpoint zpracoval doručení. Váš server může vrátit 200 po commitu do databáze, která je pak vrácena zpět; load balancer může ztratit odpověď na zpáteční cestě, i když váš handler uspěl; nasazení může restartovat váš proces uprostřed požadavku.

Tři režimy selhání, pro které musíte navrhovat

Režim selhání Co se stane Co se rozbije, když to ignorujete
Duplicitní doručení Stejné ID události přijde 2+ krát Dvakrát počítané odpovědi, duplicitní zpracování STOP, duplicitní vlákna konverzace
Události mimo pořadí Událost s pozdější časovou značkou přijde před dřívější Stav "delivered" je přepsán zpět na "sent"
Částečné/nejednoznačné selhání Váš

Idempotence: jedna vlastnost, která řeší všechny tři

Idempotentní přijímací endpoint produkuje stejný konečný stav bez ohledu na to, kolikrát je stejná událost doručena. Mechanismus je jednoduchý a dobře pochopený: každá příchozí událost nese jedinečné ID události; před zpracováním kontrolujete, zda jste toto ID již zaznamenali; pokud ano, okamžitě vrátíte úspěch bez opětovného zpracování. 1.

Pořadí událostí: proč je "poslední zápis vyhrává" nebezpečné

Webhookové události pro stejnou zprávu nejsou zaručeně doručeny v pořadí, ve kterém se odehrály. Opakování dřívější události "queued" může přijít po pozdější události "delivered" kvůli síťovému jitteru, frontování na straně poskytovatele, nebo vaší vlastní skupině workerů zpracovávající požadavky mimo pořadí.

STOP, HELP a další příchozí klíčová slova vyžadují stejnou disciplínu

Příchozí klíčová slova kritická pro compliance si zaslouží nejpřísnější idempotenci ze všech. Duplicitní STOP by nikdy neměl dvakrát zaznamenat událost odhlášení ani odeslat dvě potvrzující odpovědi. Duplicitní HELP by nikdy neměl spustit dvě samostatné podpůrné informační zprávy na stejné číslo ve stejné minutě.

Začněte s IOSOR

Související: smyčky auto-odpovědí inbound · Vyrovnávací paměť příchozích webhooků proti výkyvům latence operátorů · rezervace předplaceného zůstatku před prvním stržením.

Shrnutí IOSOR

Inbound webhooky dělají retry. Idempotence na příjmu je jediná bezpečná odpověď; pořadí není slib.

Dělejte: klíčujte událost a ignorujte dvojče. Nedělejte: last-write-wins na STOP ani dvě stržení za stejnou událost.

Byl tento průvodce užitečný?

Související průvodci