IOSOR

IOSOR Viden

Indgående SMS-webhooks: gentagelser, hændelsesrækkefølge og idempotens ved modtagelse

En byggeguide til B2B-teams, der håndterer indgående SMS: hvorfor gentagelser sker, hvorfor hændelsesrækkefølgen ikke er garanteret, og hvordan man gør sit modtagelsesendpoint idempotent i stedet for at duplikere samtaler og STOP-håndtering.

Enhver håndtering af indgående beskeder støder til sidst på de samme tre overraskelser: den samme webhook affyres to gange, en "delivered"-hændelse ankommer efter den "failed", den skulle erstatte, og en kundes STOP-svar behandles to gange, fordi to servere modtog den samme gentagelse. Intet af dette er en fejl i platformen, der sender jer webhooken — det er den normale opførsel af ethvert "mindst én gang"-leveringssystem, og jeres modtagelsesendpoint skal bygges til denne virkelighed fra dag ét.

IOSOR leverer indgående SMS, STOP/HELP-nøgleord og leveringshændelser som white-label forudbetalte webhooks — den nedenfor beskrevne gentagelses- og rækkefølgeadfærd er, hvad enhver seriøs B2B-integration bør antage, uanset hvilken platform der ligger bagved.

Hvorfor webhooks overhovedet gentager

En webhook-udbyder kan ikke med sikkerhed vide, om jeres endpoint behandlede en levering. Jeres server kan returnere en 200 efter at have committet til en database, der derefter rulles tilbage; en load balancer kan miste svaret på vejen tilbage, selvom jeres handler lykkedes; en deployment kan genstarte jeres proces midt i en forespørgsel.

De tre fejltilstande, I skal designe til

Fejltilstand Hvad der sker Hvad der går i stykker, hvis I ignorerer det
Dupliceret levering Samme hændelses-ID ankommer 2+ gange Dobbelttalte svar, dupliceret STOP-behandling, duplikerede samtaletråde
Hændelser uden for rækkefølge En senere tidsstemplet hændelse ankommer før en tidligere En "delivered"-status overskrives tilbage til "sent"
Delvis/tvetydig

Idempotens: den ene egenskab, der løser alle tre

Et idempotent modtagelsesendpoint producerer samme sluttilstand, uanset hvor mange gange den samme hændelse leveres. Mekanismen er enkel og velforstået: hver indgående hændelse bærer et unikt hændelses-ID; før behandling kontrollerer I, om I allerede har registreret dette ID; hvis ja, returnerer I straks succes uden at genbehandle. 1.

Hændelsesrækkefølge: hvorfor "sidste skrivning vinder" er farligt

Webhook-hændelser for den samme besked er ikke garanteret at ankomme i den rækkefølge, de fandt sted i. En gentagelse af en tidligere "queued"-hændelse kan ankomme efter en senere "delivered"-hændelse på grund af netværksjitter, kødannelse på udbydersiden, eller jeres egen worker-pool, der behandler forespørgsler uden for rækkefølge.

STOP, HELP og andre indgående nøgleord kræver samme disciplin

Compliance-kritiske indgående nøgleord fortjener den strengeste idempotens af alle. En dupliceret STOP bør aldrig logge en frameldingshændelse to gange eller sende to bekræftelsessvar. En dupliceret HELP bør aldrig udløse to separate supportinfobeskeder til samme nummer inden for samme minut.

Kom i gang med IOSOR

Relateret: inbound autosvar-løkker · Buffer indgående webhook-behandling mod spidser i operatørens latens · reservation af forudbetalt saldo før første debitering.

IOSOR takeaway

Inbound-webhooks retrier. Idempotens ved modtagelse er det eneste sikre svar; rækkefølge er ikke et løfte.

Gør: nøgle eventet og ignorér tvillingen. Gør ikke: last-write-wins på STOP eller træk samme event to gange.

Var denne guide nyttig?

Relaterede vejledninger