ইনবাউন্ড SMS ওয়েবহুক: রিট্রাই, ইভেন্ট ক্রম ও গ্রহণে আইডেম্পোটেন্সি

আউটবাউন্ড SMS ড্যাশবোর্ড দখল করে। ইনবাউন্ড সেই জায়গা যেখানে STOP, HELP ও গ্রাহক উত্তর সত্যি অবতরণ করে — এবং যেখানে সরল হ্যান্ডলার ডুপ্লিকেট টিকিট, দ্বৈত ওয়ালেট সাইড-ইফেক্ট ও “আমরা কখনো STOP পাইনি” compliance ভূত তৈরি করে। যদি আপনার রিসিভ পাথ exactly-once ও ক্রমানুসারে ধরে নেয়, প্রথম আসল আউটজেই ভেঙে পড়বেন।.

IOSOR ইনবাউন্ড মেসেজিংকে আউটবাউন্ডের মতো একই হোয়াইট-লেবেল প্রিপেইড পৃষ্ঠে রাখে: যাচাইযোগ্য ইভেন্ট, ব্র্যান্ড-নিরাপদ পেলোড, উত্তরের ঝড় মেলাতে বিদেশি ops পোর্টালে বাস না করেই।.

ওয়েবহুক কেন আদৌ আবার চেষ্টা করে

অধিকাংশ প্ল্যাটফর্মে ইনবাউন্ড ওয়েবহুক রিট্রাইসহ at-least-once ডেলিভারি প্রতিশ্রুতি দেয়, জাদুকরী exactly-once কঠোর ক্রম নয়। আপনার হ্যান্ডলারকে সহ্য করতে হবে:

• একই লজিক্যাল ইভেন্টের ডুপ্লিকেট POST
• টাইমআউটের পর দেরিতে আসা
• অন্য ইভেন্ট ধরনের তুলনায় মাঝেমধ্যে out-of-order

প্রোডাক্ট UX তবু ক্রমবদ্ধ মনে হতে পারে যদি আপনার স্টোর নির্ধারক মার্জ করে — যদি আশা করেন তার কখনো কাঁপবে না, তাহলে নয়।.

তিনটি ব্যর্থতা মোড যার জন্য ডিজাইন করতেই হবে

আইডেমপোটেন্সি: একটি বৈশিষ্ট্য যা তিনটিকেই ঠিক করে

ইভেন্ট ক্রম: কেন “last write wins” বিপজ্জনক

সাধারণ ভুল ধারণা:

1. STOP পরবর্তী মার্কেটিং সেন্ডের আগে আসবে (রেস আছে)
2. আউটবাউন্ড DLR ইনবাউন্ড রিপ্লাইয়ের আগে আসবে (স্বাধীন পথ)
3. টেকসই ইভেন্ট কি ছাড়া “প্রথম POST জেতে”

টেকসই event / message id দিয়ে রিসিভ লেজার গড়ুন। ব্যবসায়িক নিয়ম সেই লেজারের স্টেট ট্রানজিশন হোক, “প্রতিটি HTTP 200 পথে সাইড ইফেক্ট” নয়।.

1. ইনবাউন্ড কলব্যাকের নথিভুক্ত রিট্রাই নীতি
2. পরীক্ষাযোগ্য স্বাক্ষর / auth যাচাই
3. পেলোডে টেকসই event id
4. আইডেম্পোটেন্ট হ্যান্ডলার নির্দেশনা (শুধু “২০০ ফেরান” নয়)
5. ডুপ্লিকেট ডেলিভারিতে টিকে থাকা STOP / HELP পথ
6. যেকোনো অটো-রিপ্লাই খরচে একই প্রিপেইড ওয়ালেট দৃশ্যমানতা

STOP, HELP এবং অন্যান্য ইনবাউন্ড কীওয়ার্ডে একই শৃঙ্খলা

IOSOR দিয়ে শুরু করুন

গত সপ্তাহের আগত webhook লগ টানুন এবং একাধিকবার আসা ইভেন্ট ID গণনা করুন। এক ডুপ্লিকেট ও এক ক্রম-বাইরের জোড়া চালান (failed, তারপর delivered)। রিসিভার এক প্রভাব রাখে: এক ইনবক্স সারি, এক STOP লেখা, এক ওয়ালেট ছোঁয়া। STOP উল্টানো last-write-wins ব্যর্থতা। এটি গ্রহণে আইডেমপোটেন্সি ও পুনঃচেষ্টা ক্রম, স্বাক্ষর যাচাই নয়, সারির আগে গেটওয়ে তালা নয়।

সম্পর্কিত: ইনবাউন্ড অটো-রিপ্লাই লুপ · IOSOR-এ ক্যারিয়ার লেটেন্সি স্পাইków রোধে ইনবাউন্ড ওয়েбহুক বাফার কনফিগারেশন · প্রথম ডেবিটের আগে প্রিপেইড অর্থ সংরক্ষণ.

IOSOR সারাংশ

আগত webhook আবার চেষ্টা করে। গ্রহণে আইডেমপোটেন্সিই নিরাপদ উত্তর; ক্রম প্রতিশ্রুতি নয়।

করুন: ইভেন্টে চাবি দিন এবং যমজ উপেক্ষা করুন। করবেন না: STOP-এ last-write-wins বা একই ইভেন্ট দুবার কর্তন নয়।