IOSOR

IOSOR Kunnskap

Innkommende SMS-webhooker: gjentakelser, hendelsesrekkefølge, og idempotens ved mottak

En byggeguide for B2B-team som håndterer innkommende SMS: hvorfor gjentakelser skjer, hvorfor hendelsesrekkefølgen ikke er garantert, og hvordan gjøre mottaksendepunktet idempotent i stedet for å duplisere samtaler og STOP-håndtering.

Når du tar imot innkommende SMS via webhooker, vil du raskt oppleve at samme hendelse sendes flere ganger eller at meldinger ankommer i feil rekkefølge. Dette er ikke en feil, men normal oppførsel i et system med minst-én-gang-levering. For å unngå dupliserte handlinger må mottaksendepunktet ditt bygges idempotent med meldings-ID som unik nøkkel fra dag én.

Hvorfor webhooker i det hele tatt prøver på nytt

En webhook-leverandør kan ikke med sikkerhet vite om endepunktet ditt behandlet en levering. Serveren din kan returnere en 200 etter å ha forpliktet seg til en database som deretter rulles tilbake; en lastbalanserer kan miste svaret på veien tilbake selv om håndtereren din lyktes; en distribusjon kan starte prosessen din på nytt midt i en forespørsel.

De tre feilmodusene du må designe for

Feilmodus Hva som skjer Hva som går i stykker hvis du ignorerer det
Duplisert levering Samme hendelses-ID kommer 2+ ganger Dobbelttalte svar, duplisert STOP-behandling, dupliserte samtaletråder
Hendelser utenfor rekkefølge En senere tidsstemplet hendelse kommer før en tidligere En "delivered"-status overskrives tilbake til "sent"
Delvis/tvetydig feil Håndtereren din behandlet hendelsen, men bekreftelsen gikk tapt Leverandøren prøver på nytt noe du allerede har gjort

Idempotens: den ene egenskapen som løser alle tre

Et idempotent mottaksendepunkt produserer samme sluttilstand uansett hvor mange ganger den samme hendelsen leveres. Mekanismen er enkel og godt forstått: hver innkommende hendelse bærer en unik hendelses-ID; før behandling sjekker du om du allerede har registrert den ID-en; hvis ja, returnerer du suksess umiddelbart uten å behandle på nytt. 1. Trekk ut leverandørens hendelse-/melding-ID fra payload — finn aldri opp din egen fra tidsstempel + innhold, siden gjentakelser kan forskyve tidsstempler med millisekunder. 2.

Hendelsesrekkefølge: hvorfor "siste skriving vinner" er farlig

Webhook-hendelser for samme melding er ikke garantert å ankomme i den rekkefølgen de skjedde. En gjentakelse av en tidligere "queued"-hendelse kan ankomme etter en senere "delivered"-hendelse på grunn av nettverksjitter, køing på leverandørsiden, eller din egen worker-pool som behandler forespørsler utenfor rekkefølge. Hvis håndtereren din bare overskriver meldingens statuskolonne med det som nettopp har ankommet, kan en sent ankommende foreldet hendelse stille regressere en levert melding tilbake til en tidligere tilstand.

STOP, HELP, og andre innkommende nøkkelord trenger samme disiplin

Compliance-kritiske innkommende nøkkelord fortjener den strengeste idempotensen av alle. En duplisert STOP bør aldri logge en avmeldingshendelse to ganger eller sende to bekreftelsessvar. En duplisert HELP bør aldri utløse to separate support-info-meldinger til samme nummer innen samme minutt.

Start med IOSOR

I konsollen: Inbound SMS webhook retries stay idempotent; no double MO side-effects.. Navngi eier og gates før skalering.

Relatert: inbound autoreply loop wallet drain inbound carrier latency webhook time

IOSOR-oppsummering

Ops-disiplin for vakten—ikke brochure.

Gjør: name owner + gate. Ikke: skip the gate.

Var denne guiden nyttig?

Relaterte veiledninger