IOSOR

IOSOR Panduan

Webhook SMS masuk: percobaan ulang, urutan peristiwa, dan idempotensi saat menerima

Panduan pembuatan untuk tim B2B yang menangani SMS masuk: mengapa percobaan ulang terjadi, mengapa urutan peristiwa tidak dijamin, dan bagaimana membuat endpoint penerimaan Anda idempoten alih-alih menduplikasi percakapan dan penanganan STOP.

Setiap penangan pesan masuk pada akhirnya menghadapi tiga kejutan yang sama: webhook yang sama terpicu dua kali, peristiwa "delivered" tiba setelah "failed" yang seharusnya digantikannya, dan balasan STOP pelanggan diproses dua kali karena dua server menerima percobaan ulang yang sama. Tak satu pun dari ini adalah bug pada platform yang mengirimi Anda webhook — ini adalah perilaku normal dari sistem pengiriman "setidaknya sekali" mana pun, dan endpoint penerimaan Anda harus dibangun untuk realitas ini sejak hari pertama.

Mengapa webhook mencoba ulang sama sekali

Penyedia webhook tidak dapat mengetahui dengan pasti apakah endpoint Anda memproses pengiriman. Server Anda mungkin mengembalikan 200 setelah melakukan commit ke database yang kemudian di-rollback; load balancer mungkin kehilangan respons dalam perjalanan kembali meskipun handler Anda berhasil; deploy mungkin me-restart proses Anda di tengah permintaan.

Tiga mode kegagalan yang harus Anda rancang

Mode kegagalan Apa yang terjadi Apa yang rusak jika Anda mengabaikannya
Pengiriman duplikat ID peristiwa yang sama tiba 2+ kali Balasan terhitung ganda, pemrosesan STOP duplikat, thread percakapan duplikat
Peristiwa tidak berurutan Peristiwa dengan stempel waktu lebih lambat tiba sebelum yang lebih awal Status "delivered" ditimpa kembali menjadi "sent"
Kegagalan parsial/ambigu

Idempotensi: satu properti yang memperbaiki ketiganya

Endpoint penerimaan idempoten menghasilkan status akhir yang sama tidak peduli berapa kali peristiwa yang sama dikirim. Mekanismenya sederhana dan dipahami dengan baik: setiap peristiwa masuk membawa ID peristiwa unik; sebelum memproses, Anda memeriksa apakah Anda sudah mencatat ID tersebut; jika ya, Anda mengembalikan sukses segera tanpa memproses ulang. 1.

Urutan peristiwa: mengapa "penulisan terakhir menang" berbahaya

Peristiwa webhook untuk pesan yang sama tidak dijamin tiba dalam urutan terjadinya. Percobaan ulang dari peristiwa "queued" sebelumnya dapat tiba setelah peristiwa "delivered" berikutnya karena jitter jaringan, antrean di sisi penyedia, atau pool worker Anda sendiri yang memproses permintaan tidak berurutan.

STOP, HELP, dan kata kunci masuk lainnya membutuhkan disiplin yang sama

Kata kunci masuk yang kritis terhadap kepatuhan pantas mendapatkan idempotensi paling ketat dari semuanya. STOP duplikat tidak boleh pernah mencatat peristiwa opt-out dua kali atau mengirim dua balasan konfirmasi. HELP duplikat tidak boleh pernah memicu dua pesan info dukungan terpisah ke nomor yang sama dalam menit yang sama.

Mulai dengan IOSOR

Tarik log webhook masuk minggu lalu dan hitung ID peristiwa yang datang lebih dari sekali. Putar ulang satu salinan dan satu pasangan di luar urutan (failed, lalu delivered). Penerima menyimpan satu efek: satu baris kotak masuk, satu tulis STOP, satu sentuh dompet. Last-write-wins yang membatalkan STOP gagal. Ini idempotensi di penerimaan dan urutan coba ulang, bukan validasi tanda tangan dan bukan gembok gerbang sebelum antrean.

Intisari IOSOR

Webhook masuk mencoba ulang. Idempotensi di penerimaan satu-satunya jawaban aman; urutan bukan janji.

Lakukan: kunci peristiwa dan abaikan kembar. Jangan: last-write-wins pada STOP atau debit peristiwa yang sama dua kali.

Apakah panduan ini membantu?

Panduan terkait