IOSOR

IOSOR Znanje

Dolazni SMS webhookovi: ponovni pokušaji, redoslijed događaja, i idempotencija pri primanju

Vodič za izgradnju za B2B timove koji upravljaju dolaznim SMS-om: zašto se događaju ponovni pokušaji, zašto redoslijed događaja nije zajamčen, i kako učiniti vašu krajnju točku za primanje idempotentnom umjesto duplicirati razgovore i obradu STOP-a.

Svaki rukovatelj dolaznim porukama u konačnici nailazi na ista tri iznenađenja: isti webhook se aktivira dva puta, događaj "delivered" stiže nakon "failed" koji je trebao zamijeniti, i STOP odgovor klijenta obrađuje se dva puta jer su dva poslužitelja primila isti ponovni pokušaj. Ništa od ovoga nije bug platforme koja vam šalje webhook — to je normalno ponašanje bilo kojeg sustava dostave "barem jednom", a vaša krajnja točka za primanje mora biti izgrađena za tu stvarnost od prvog dana.

Zašto webhookovi uopće ponovno pokušavaju

Pružatelj webhooka ne može sa sigurnošću znati je li vaša krajnja točka obradila dostavu. Vaš poslužitelj može vratiti 200 nakon što se obveže na bazu podataka koja se zatim vraća unazad; balansir opterećenja može izgubiti odgovor na povratnom putu iako je vaš rukovatelj uspio; implementacija može ponovno pokrenuti vaš proces usred zahtjeva.

Tri načina kvara za koje morate dizajnirati

Način kvara Što se događa Što se pokvari ako to ignorirate
Duplicirana dostava Isti ID događaja stiže 2+ puta Dvostruko brojani odgovori, duplicirana obrada STOP-a, duplicirane niti razgovora
Događaji izvan reda Događaj s kasnijom vremenskom oznakom stiže prije ranijeg Status "delivered" se prepisuje natrag na "sent"
Djelomični/dvosmisleni kvar Vaš rukovatelj obradio je događaj, ali

Idempotencija: jedno svojstvo koje rješava sva tri

Idempotentna krajnja točka za primanje proizvodi isto konačno stanje bez obzira koliko puta se isti događaj dostavi. Mehanizam je jednostavan i dobro shvaćen: svaki dolazni događaj nosi jedinstveni ID događaja; prije obrade, provjeravate jeste li već zabilježili taj ID; ako jeste, odmah vraćate uspjeh bez ponovne obrade. 1.

Redoslijed događaja: zašto je "posljednji zapis pobjeđuje" opasno

Webhook događaji za istu poruku nisu zajamčeni da stižu redoslijedom kojim su se dogodili. Ponovni pokušaj ranijeg događaja "queued" može stići nakon kasnijeg događaja "delivered" zbog mrežnog jittera, redova na strani pružatelja, ili vašeg vlastitog bazena radnika koji obrađuje zahtjeve izvan reda.

Crvene zastavice

  • Nema jedinstvenog ID-a događaja u payload-u webhooka, ili vaša integracija zanemaruje postojeći
  • Ažuriranja statusa primijenjena jednostavnim prepisivanjem bez usporedbe vremenske oznake
  • Obrada STOP-a koja nije iza iste logike deduplikacije kao redovne dolazne poruke
  • Webhook rukovatelj obavlja sinkrone silazne pozive (e-pošta, CRM, usmjeravanje agenta) prije potvrde
  • Nema zapisa koji pokazuju koliko je dupliciranih ID-ova događaja stiglo prošli

Počnite s IOSOR-om

Povezano: petlje inbound auto-odgovora · Ublažavanje latencije dolaznih mrežnih veza za webhooks u CPaaS platformama · rezervacija prepaid salda prije prvog terećenja.

Sažetak IOSOR

Inbound webhookovi ponavljaju. Idempotencija na primitku jedini je siguran odgovor; redoslijed nije obećanje.

Radite: ključajte događaj i ignorirajte blizanca. Nemojte: last-write-wins na STOP niti dva terećenja za isti događaj.

Je li vam ovaj vodič pomogao?

Povezani vodiči