IOSOR

IOSOR Tudás

Bejövő SMS-webhookok: újrapróbálkozások, eseménysorrend, és idempotencia fogadáskor

Építési útmutató B2B csapatoknak, akik bejövő SMS-eket kezelnek: miért történnek újrapróbálkozások, miért nem garantált az eseménysorrend, és hogyan tegye idempotenssé a fogadó végpontját ahelyett, hogy megkettőzné a beszélgetéseket és a STOP-kezelést.

Minden bejövő üzenetkezelő végül ugyanazzal a három meglepetéssel találkozik: ugyanaz a webhook kétszer sül el, egy „delivered" esemény azután érkezik meg, mint a „failed", amelyet le kellett volna cserélnie, és egy ügyfél STOP válaszát kétszer dolgozzák fel, mert két szerver kapta meg ugyanazt az újrapróbálkozást. Ezek közül semmi sem hiba a platformban, amely elküldi Önnek a webhookot — ez bármely „legalább egyszer" kézbesítési rendszer normális viselkedése, és a fogadó végpontjának az első naptól kezdve erre a valóságra kell épülnie.

Miért próbálkoznak egyáltalán újra a webhookok

Egy webhook szolgáltató nem tudhatja biztosan, hogy a végpontja feldolgozott-e egy kézbesítést. Az Ön szervere visszaadhat egy 200-as választ egy adatbázis-commitolás után, amelyet aztán visszagörgetnek; egy terheléselosztó elveszítheti a választ a visszaúton, annak ellenére, hogy a kezelője sikeres volt; egy telepítés újraindíthatja a folyamatát egy kérés közepén.

A három hibamód, amelyre tervezni kell

Hibamód Mi történik Mi romlik el, ha figyelmen kívül hagyja
Duplikált kézbesítés Ugyanaz az esemény-ID 2+ alkalommal érkezik Duplán számolt válaszok, duplikált STOP-feldolgozás, duplikált beszélgetésszálak
Sorrenden kívüli események Egy későbbi időbélyegű esemény korábban érkezik, mint egy korábbi Egy „delivered" állapot visszaíródik „sent"-re
Részleges/kétértelmű hiba A kezelője

Idempotencia: az egyetlen tulajdonság, amely mindhármat megoldja

Egy idempotens fogadó végpont ugyanazt a végállapotot állítja elő, függetlenül attól, hányszor kézbesítik ugyanazt az eseményt. A mechanizmus egyszerű és jól ismert: minden bejövő esemény egyedi esemény-ID-t hordoz; feldolgozás előtt ellenőrzi, hogy már rögzítette-e ezt az ID-t; ha igen, azonnal sikert ad vissza újrafeldolgozás nélkül. 1.

Eseménysorrend: miért veszélyes a „legutolsó írás nyer"

Ugyanazon üzenet webhook eseményei nem garantáltan érkeznek meg abban a sorrendben, amelyben történtek. Egy korábbi „queued" esemény újrapróbálkozása később érkezhet meg, mint egy későbbi „delivered" esemény, hálózati jitter, szolgáltatóoldali sorba állítás, vagy a saját worker poolja miatt, amely sorrenden kívül dolgozza fel a kéréseket.

Piros zászlók

  • Nincs egyedi esemény-ID a webhook payloadban, vagy az integrációja figyelmen kívül hagyja a meglévőt
  • Az állapotfrissítéseket egyszerű felülírással alkalmazzák időbélyeg-összehasonlítás nélkül
  • A STOP-kezelés nincs ugyanazon dedup logika mögött, mint a normál bejövő üzenetek
  • A webhook kezelő szinkron downstream hívásokat végez (e-mail, CRM, ügynökhöz irányítás) a nyugtázás előtt
  • Nincsenek naplók, amelyek megmutatnák, hány duplikált esemény-ID

Kezdje az IOSOR-ral

Kapcsolódó: beérkező automatikus válaszhurkok · Bejövő webhook folyamatok pufferelése a szolgáltatói késleltetési csúcsok ellen · előre fizetett egyenleg zárolása az első terhelés előtt.

IOSOR összegzés

Az inbound webhookok újrapróbálnak. A fogadási idempotencia az egyetlen biztonságos válasz; a sorrend nem ígéret.

Tegyék: kulcsolják az eseményt, és hagyják figyelmen kívül az ikert. Ne tegyék: last-write-wins a STOP-on, vagy ugyanazt az eseményt kétszer terhelni.

Hasznos volt ez az útmutató?

Kapcsolódó útmutatók