IOSOR

IOSOR Wiedza

Webhooki SMS przychodzących: ponowienia, kolejność zdarzeń i idempotencja przy odbiorze

Przewodnik budowy dla zespołów B2B obsługujących SMS-y przychodzące: dlaczego zdarzają się ponowienia, dlaczego kolejność zdarzeń nie jest gwarantowana, i jak sprawić, by punkt końcowy odbioru był idempotentny zamiast duplikować rozmowy i obsługę STOP.

Każdy system obsługujący webhooki SMS przychodzących musi zmierzyć się z powielonymi zapytaniami, zaburzoną kolejnością zdarzeń oraz wielokrotnym przetwarzaniem tych samych komend. Odbieranie danych w modelu at-least-once wymaga projektowania endpointów z myślą o pełnej idempotencji i weryfikacji unikalnych identyfikatorów wiadomości. Brak odpowiedniej architektury prowadzi do błędów w logice biznesowej, takich jak podwójne wypisywanie użytkowników z list odbiorców.

Dlaczego webhooki w ogóle ponawiają

Dostawca webhooków nie może mieć pewności, że wasz punkt końcowy przetworzył dostawę. Wasz serwer może zwrócić 200 po zatwierdzeniu transakcji w bazie danych, która następnie zostaje wycofana; load balancer może zgubić odpowiedź w drodze powrotnej, mimo że wasz handler zakończył się sukcesem; wdrożenie może zrestartować wasz proces w połowie żądania.

Trzy tryby awarii, dla których musicie projektować

Tryb awarii Co się dzieje Co się psuje, jeśli to zignorujecie
Duplikat dostawy Ten sam ID zdarzenia przychodzi 2+ razy Podwójnie policzone odpowiedzi, zduplikowane przetwarzanie STOP, zduplikowane wątki rozmów
Zdarzenia poza kolejnością Zdarzenie z późniejszym znacznikiem czasu przychodzi przed wcześniejszym Status "delivered" zostaje nadpisany z powrotem na "sent"
Częściowa/niejednoznaczna awaria Wasz

Idempotencja: jedna właściwość, która rozwiązuje wszystkie trzy

Idempotentny punkt końcowy odbioru wytwarza ten sam stan końcowy niezależnie od tego, ile razy to samo zdarzenie zostanie dostarczone. Mechanizm jest prosty i dobrze zrozumiany: każde zdarzenie przychodzące niesie unikalny ID zdarzenia; przed przetworzeniem sprawdzacie, czy już zarejestrowaliście ten ID; jeśli tak, zwracacie sukces natychmiast bez ponownego przetwarzania. 1.

Kolejność zdarzeń: dlaczego "ostatni zapis wygrywa" jest niebezpieczne

Zdarzenia webhook dla tej samej wiadomości nie są gwarantowane przychodzić w kolejności, w jakiej wystąpiły. Ponowienie wcześniejszego zdarzenia "queued" może przyjść po późniejszym zdarzeniu "delivered" z powodu jittera sieciowego, kolejkowania po stronie dostawcy, lub waszej własnej puli workerów przetwarzającej żądania poza kolejnością.

Czerwone flagi

  • Brak unikalnego ID zdarzenia w payload webhook, lub wasza integracja ignoruje ten, który istnieje
  • Aktualizacje statusu stosowane przez proste nadpisanie bez porównania znacznika czasu
  • Obsługa STOP, która nie jest za tą samą logiką deduplikacji co zwykłe wiadomości przychodzące
  • Handler webhook wykonuje synchroniczne wywołania downstream (email, CRM, kierowanie do agenta) przed potwierdzeniem
  • Brak logów pokazujących, ile zduplikowanych ID zdarzeń przyszło w zeszłym miesiącu —

Zacznijcie z IOSOR

Wyciągnijcie logi webhook inbound z tygodnia i policzcie ID zdarzeń, które przyszły więcej niż raz. Odtwórzcie jeden dubel i jedną parę poza kolejnością (failed, potem delivered). Odbiornik trzyma jeden skutek: jeden wiersz inbox, jeden zapis STOP, jedno dotknięcie portfela. Last-write-wins, które cofa STOP, obala robotę. To idempotencja na odbiorze i kolejność retry, nie walidacja podpisu i nie blokada bramy przed kolejką.

Podsumowanie IOSOR

Webhooki inbound robią retry. Idempotencja na odbiorze to jedyna bezpieczna odpowiedź; kolejność nie jest obietnicą.

Róbcie: kluczujcie zdarzenie i ignorujcie bliźniaka. Nie róbcie: last-write-wins na STOP ani dwóch obciążeń za to samo zdarzenie.

Czy ten przewodnik był pomocny?

Powiązane przewodniki