IOSOR

IOSOR Ghiduri

Webhook-uri SMS de intrare: reîncercări, ordinea evenimentelor, și idempotență la recepție

Un ghid de construcție pentru echipele B2B care gestionează SMS-uri de intrare: de ce apar reîncercările, de ce ordinea evenimentelor nu este garantată, și cum să faceți endpoint-ul dumneavoastră de recepție idempotent în loc să duplicați conversațiile și gestionarea STOP.

Fiecare handler pentru mesajele primite se lovește inevitabil de trei mari provocări: webhook-uri duplicate, evenimente sosite într-o ordine incorectă și procesarea repetată a comenzilor de tip STOP. Aceste situații nu sunt erori, ci comportamentul firesc al oricărui sistem de livrare de tipul cel puțin o dată. Endpoint-ul dumneavoastră de recepție trebuie să fie proiectat special pentru a gestiona nativ reîncercările și idempotența încă din prima zi.

De ce webhook-urile reîncearcă deloc

Un furnizor de webhook nu poate ști cu certitudine dacă endpoint-ul dumneavoastră a procesat o livrare. Serverul dumneavoastră poate returna un 200 după ce a comis într-o bază de date care apoi este anulată; un load balancer poate pierde răspunsul pe drumul de întoarcere chiar dacă handler-ul dumneavoastră a avut succes; o implementare poate reporni procesul dumneavoastră în mijlocul unei cereri.

Cele trei moduri de eșec pentru care trebuie să proiectați

Mod de eșec Ce se întâmplă Ce se strică dacă îl ignorați
Livrare duplicată Același ID de eveniment sosește de 2+ ori Răspunsuri numărate dublu, procesare STOP duplicată, fire de conversație duplicate
Evenimente în afara ordinii Un eveniment cu marcaj temporal ulterior sosește înainte de unul anterior Un status "delivered" este suprascris înapoi la "sent"
Eșec

Idempotență: singura proprietate care rezolvă toate trei

Un endpoint de recepție idempotent produce aceeași stare finală indiferent de câte ori este livrat același eveniment. Mecanismul este simplu și bine înțeles: fiecare eveniment de intrare poartă un ID unic de eveniment; înainte de procesare, verificați dacă ați înregistrat deja acel ID; dacă da, returnați succes imediat fără reprocesare. 1.

Ordinea evenimentelor: de ce "ultima scriere câștigă" este periculos

Evenimentele webhook pentru același mesaj nu sunt garantate să sosească în ordinea în care s-au întâmplat. O reîncercare a unui eveniment anterior "queued" poate sosi după un eveniment ulterior "delivered" din cauza jitter-ului de rețea, coadă pe partea furnizorului, sau propriul dumneavoastră pool de workeri care procesează cereri în afara ordinii.

STOP, HELP, și alte cuvinte cheie de intrare necesită aceeași disciplină

Cuvintele cheie de intrare critice pentru conformitate merită cea mai strictă idempotență dintre toate. Un STOP duplicat nu ar trebui niciodată să înregistreze de două ori un eveniment de opt-out sau să trimită două răspunsuri de confirmare. Un HELP duplicat nu ar trebui niciodată să declanșeze două mesaje separate de informații de suport către același număr în același minut.

Începeți cu IOSOR

Trageți jurnalele webhook inbound de săptămâna trecută și numărați ID-urile de eveniment venite de mai multe ori. Reluați un dublu și o pereche în afara ordinii (failed, apoi delivered). Receptorul păstrează un efect: un rând inbox, o scriere STOP, o atingere de portofel. Last-write-wins care anulează STOP pică. Este idempotență la primire și ordine de reîncercări, nu validare de semnătură și nu lacăt de gateway înainte de coadă.

Rezumat IOSOR

Webhook-urile inbound reîncearcă. Idempotența la primire e singurul răspuns sigur; ordinea nu e promisiune.

Faceți: cheiați evenimentul și ignorați geamănul. Nu faceți: last-write-wins pe STOP nici două debite pentru același eveniment.

A fost util acest ghid?

Ghiduri conexe