IOSOR

IOSOR Panduan

Webhook SMS masuk: percubaan semula, susunan peristiwa, dan idempotensi semasa menerima

Panduan pembinaan untuk pasukan B2B yang mengendalikan SMS masuk: mengapa percubaan semula berlaku, mengapa susunan peristiwa tidak dijamin, dan cara menjadikan titik akhir penerimaan anda idempoten dan bukannya menduplikasi perbualan dan pengendalian STOP.

Apabila menerima webhook SMS masuk, anda mesti menjangka panggilan bertindih, susunan peristiwa yang tidak mengikut urutan, dan hantaran semula automatik disebabkan rangkaian terputus. Kegagalan mengendalikan idempotensi boleh menyebabkan kunci STOP pelanggan diproses berulang kali atau data status mesej menjadi rosak. Untuk memastikan sistem kekal stabil, titik akhir anda wajib menyemak ID unik peristiwa dan menyalin rekod secara selamat sebelum memproses sebarang muatan data.

Mengapa webhook mencuba semula sama sekali

Penyedia webhook tidak boleh tahu dengan pasti sama ada titik akhir anda memproses penghantaran. Pelayan anda mungkin mengembalikan 200 selepas melakukan komit ke pangkalan data yang kemudian di-rollback; pengimbang beban mungkin kehilangan respons dalam perjalanan pulang walaupun pengendali anda berjaya; penggunaan mungkin memulakan semula proses anda di tengah-tengah permintaan.

Tiga mod kegagalan yang mesti anda reka bentuk

Mod kegagalan Apa yang berlaku Apa yang rosak jika anda mengabaikannya
Penghantaran pendua ID peristiwa yang sama tiba 2+ kali Balasan dikira berganda, pemprosesan STOP pendua, benang perbualan pendua
Peristiwa tidak tersusun Peristiwa dengan cap masa lebih lambat tiba sebelum yang lebih awal Status "delivered" ditulis semula kembali kepada "sent"
Kegagalan separa/tidak jelas Pengendali anda memproses peristiwa tetapi pengakuan hilang Penyedia mencuba semula sesuatu yang telah anda lakukan .

Idempotensi: satu ciri yang membetulkan ketiga-tiganya

Titik akhir penerimaan idempoten menghasilkan keadaan akhir yang sama tidak kira berapa kali peristiwa yang sama dihantar. Mekanismenya mudah dan difahami dengan baik: setiap peristiwa masuk membawa ID peristiwa unik; sebelum memproses, anda menyemak sama ada anda telah merekodkan ID itu; jika ya, anda mengembalikan kejayaan serta-merta tanpa memproses semula. 1.

Susunan peristiwa: mengapa "tulisan terakhir menang" berbahaya

Peristiwa webhook untuk mesej yang sama tidak dijamin tiba dalam susunan ia berlaku. Percubaan semula peristiwa "queued" sebelumnya boleh tiba selepas peristiwa "delivered" kemudian disebabkan oleh jitter rangkaian, baris gilir di pihak penyedia, atau kumpulan pekerja anda sendiri memproses permintaan tidak tersusun. Jika pengendali anda hanya menulis semula lajur status mesej dengan apa yang baru tiba, peristiwa basi yang lewat tiba boleh secara senyap mengundur mesej yang dihantar kembali ke keadaan sebelumnya.

Bendera merah

  • Tiada ID peristiwa unik dalam payload webhook, atau integrasi anda mengabaikan yang sedia ada
  • Kemas kini status digunakan dengan tulisan semula ringkas tanpa perbandingan cap masa
  • Pengendalian STOP yang tidak berada di belakang logik dedupe yang sama seperti mesej masuk biasa
  • Pengendali webhook membuat panggilan hiliran segerak (e-mel, CRM, penghalaan ejen) sebelum pengakuan
  • Tiada log menunjukkan berapa banyak ID peristiwa pendua tiba bulan lepas — bermakna tiada siapa yang memerhati.

Bermula dengan IOSOR

Di konsol: Inbound SMS webhook retries stay idempotent; no double MO side-effects.. Namakan pemilik dan pintu sebelum scale.

Berkaitan: inbound autoreply loop wallet drain inbound carrier latency webhook time.

Inti IOSOR

Ini disiplin ops boleh tugas—bukan brochure.

Lakukan: name owner + gate. Jangan: skip the gate.

Adakah panduan ini membantu?

Panduan berkaitan