IOSOR

IOSOR Знания

Входящи SMS webhooks: повторни опити, ред на събитията, и идемпотентност при получаване

Ръководство за изграждане за B2B екипи, обработващи входящи SMS: защо се случват повторни опити, защо редът на събитията не е гарантиран, и как да направите вашата крайна точка за получаване идемпотентна, вместо да дублирате разговори и обработка на STOP.

Всеки обработчик на входящи съобщения в крайна сметка се сблъсква със същите три изненади: същият webhook се задейства два пъти, събитие „delivered" пристига след „failed", което трябваше да замести, и отговор STOP на клиент се обработва два пъти, защото два сървъра са получили един и същ повторен опит. Нищо от това не е бъг в платформата, която ви изпраща webhook-а — това е нормалното поведение на всяка система за доставка „поне веднъж", и вашата крайна точка за получаване трябва да бъде изградена за тази реалност от първия ден.

Защо webhooks изобщо правят повторни опити

Доставчик на webhook не може да знае със сигурност дали вашата крайна точка е обработила доставка. Вашият сървър може да върне 200 след ангажиране към база данни, която впоследствие се връща назад; балансьор на натоварването може да загуби отговора на обратния път, въпреки че вашият обработчик е успял; внедряване може да рестартира вашия процес по средата на заявка.

Трите режима на неизправност, за които трябва да проектирате

Режим на неизправност Какво се случва Какво се чупи, ако го игнорирате
Дублирана доставка Един и същ ID на събитие пристига 2+ пъти Двойно преброени отговори, дублирана обработка на STOP, дублирани нишки на разговор
Събития извън ред Събитие с по-късен времеви маркер пристига преди по-ранно Статус „delivered" се презаписва обратно на „sent"
Частична/неясна

Идемпотентност: едно свойство, което решава и трите

Идемпотентна крайна точка за получаване произвежда едно и също крайно състояние независимо от това колко пъти е доставено едно и също събитие. Механизмът е прост и добре разбран: всяко входящо събитие носи уникален ID на събитие; преди обработка, проверявате дали вече сте записали този ID; ако да, връщате успех незабавно без повторна обработка. 1.

Ред на събитията: защо „последният запис печели" е опасно

Webhook събитията за едно и също съобщение не са гарантирани да пристигнат в реда, в който са се случили. Повторен опит на по-ранно събитие „queued" може да пристигне след по-късно събитие „delivered" поради мрежов джитър, опашки от страна на доставчика, или собствения ви пул от работници, обработващи заявки извън ред.

STOP, HELP, и други входящи ключови думи изискват същата дисциплина

Входящите ключови думи, критични за съответствието, заслужават най-строгата идемпотентност от всички. Дублиран STOP никога не трябва да записва два пъти събитие за отказ или да изпраща два потвърждаващи отговора. Дублиран HELP никога не трябва да задейства две отделни съобщения с информация за поддръжка към един и същ номер в рамките на една и съща минута.

Започнете с IOSOR

Издърпайте логовете на входящите webhook от седмицата и пребройте ID на събития, дошли повече от веднъж. Пуснете един дубликат и една двойка извън ред (failed, после delivered). Приемникът държи един ефект: един ред inbox, един запис STOP, едно докосване на портфейла. Last-write-wins, което връща STOP, проваля. Това е идемпотентност на приема и ред на повтори, не проверка на подпис и не ключалка на шлюза преди опашката.

Обобщение IOSOR

Входящите webhook правят повтори. Идемпотентността на приема е единственият безопасен отговор; редът не е обещание.

Правете: ключовайте събитието и игнорирайте близнака. Не правете: last-write-wins върху STOP или две отписвания за същото събитие.

Полезно ли беше ръководството?

Свързани ръководства