কিউতে থাকা বার্তাগুলির জন্য অর্থ আটকে রাখতে হবে, প্রেরিত হিসেবে ডেবিট নয়

কিউতে থাকা বার্তাগুলির জন্য অর্থ আটকে রাখতে হবে, প্রেরিত হিসেবে ডেবিট নয়.

কেন ক্যু অবস্থায় অথরাইজেশন হোল্ডের প্রয়োজন

যখন একটি API ক্লায়েন্ট একটি উচ্চ-ভলিউম SMS বার্তার ব্যাচ বা একক OTP পেলোড জমা দেয়, তখন প্ল্যাটফর্মটি নেটওয়ার্ক প্রেরণের আগে প্রতিটি বার্তাকে কিউড স্ট্যাটাসে রাখে। API গ্রহণের সাথে সাথে কিউড বার্তাকে চড়ান্ত ডেবিট হিসাবে চিহ্নিত করলে তা গ্রাহকের বিলিং রেকর্ডকে বিকৃত করে। যদি ক্যারিয়ার রাউটিং বিলম্বিত হয় বা অবৈধ E.164 নম্বরের কারণে তাৎক্ষণিক প্রত্যাখ্যান ঘটে, তবে নিশ্চিতকরণের আগে ডেবিট করা হিসাবরক্ষণ ভুল এবং অপ্রয়োজনীয় ব্যালেন্স বিরোধ সৃষ্টি করে।

লেজার মেকানিক্স: হোল্ড লেজার বনাম চূড়ান্ত ডেবিট

যখন একটি বার্তা পাইপলাইনে প্রবেশ করে, লেজার সিস্টেম আপনার বর্তমান ব্যয়যোগ্য ব্যালেন্স যাচাই করে এবং লক্ষ্য গন্তব্য হারের সমান একটি সাময়িক ড্রাফট হোল্ড স্থাপন করে। এই হোল্ডটি ডেলিভারি ক্ষমতা নিশ্চিত করতে প্রয়োজনীয় ইউনিট লক করে এবং মূল লেজার ব্যালেন্স ঠিক রাখে। ক্যারিয়ার রাউটিং একটি আপস্ট্রিম গ্রহণ ফ্রেম বা ইতিবাচক DLR ইভেন্ট ফেরত পাঠালে, সিস্টেম চূড়ান্ত লেজার ডেবিট সম্পাদন করে।

বিশেষ পরিস্থিতি: মেয়াদোত্তীর্ণ ক্যু, টাইমআউট এবং রিভার্সাল

সিস্টেমের ভিড়, গন্তব্য নেটওয়ার্ক বিভ্রাট বা সময়িক রাউটিং ব্যর্থতার কারণে বার্তাগুলি স্বাভাবিক প্রক্রিয়াকরণ থ্রেশহোল্ডের বাইরে কিউড অবস্থায় বসে থাকতে পারে। যখন একটি কিউড বার্তা তার নির্ধারিত টাইম-টু-লাইভ মেয়াদের সীমায় পৌঁছায় বা তাৎক্ষণিক প্রত্যাখ্যানের সম্মুখীন হয়, তখন রাউটিং ইঞ্জিন প্রচেষ্টা সমাপ্ত করে। হোল্ড লেজার অবিলম্বে একটি বাতিল সংকেত পায় এবং স্বয়ংক্রিয় রিভার্সাল সম্পাদন করে।

স্কেলে মার্জিন গার্ডরেইল এবং সফ্ট রিভিউ থ্রেশহোল্ড

হঠাৎ ট্র্যাফিক বৃদ্ধির সময় পরিকাঠামোর স্থায়িত্ব নিশ্চিত করতে, অ্যাকাউন্টগুলি স্বয়ংক্রিয় ব্যালেন্স গার্ডরেইলের অধীনে কাজ করে। বহির্গামী API অনুরোধগুলি প্রক্রিয়া করতে এবং পরিষেবা বাধা ছাড়াই সক্রিয় হোল্ড সংরক্ষণ সমর্থন করতে একটি বেসলাইন USD 20 প্রিপেইড ফ্লোর প্রয়োজন। আপনার প্ল্যাটফর্মের থ্রুপুট প্রসারিত হওয়ার সাথে সাথে এবং মাসিক অ্যাকাউন্ট ব্যয় USD 1,000/মাস এর কাছাকাছি পৌঁছালে, সিস্টেমটি একটি সফ্ট রিভিউ ট্রিগার করে।

ক্যু স্টেট পরিচালনা এবং অডিট ট্রাভার্সাল

প্রকৌশলী এবং বিলিং পরিচালকরা প্ল্যাটফর্ম ওয়েবহুক এবং লগ এক্সপোর্ট ব্যবহার করে রিয়েল-টাইমে বার্তার জীবনচক্রের রূপান্তর পর্যবেক্ষণ করতে পারেন। প্রতিটি API ইভেন্ট একটি পেলোড বর্তমানে কিউড, প্রেরিত, বিতরণ করা হয়েছে নাকি ব্যর্থ হয়েছে তা নির্দেশ করে স্পষ্ট স্ট্যাটাস ফিল্ড ফেরত দেয়।

সম্পর্কিত: কিউড বনাম সেন্ট: IOSOR-এ একটি মাত্র বার্তা পথ · মেসেজ লাইফসাইকেল স্টেট বনাম কম ডেলিভারি সমাধানের গাইড · প্রথম ডেবিটের আগে প্রিপেইড অর্থ সংরক্ষণ.

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

আপনার আইওএসওআর কনসোল খুলে লেজার অডিট ট্যাবে যান এবং পাঠানো ডেবিটগুলোর বিপরীতে সক্রিয় হোল্ড রিজার্ভেশনগুলো পরীক্ষা করুন। রিয়েল-টাইমে স্বয়ংক্রিয় হোল্ড রিলিজ চক্র ট্র্যাক করতে message.queued এবং message.failed ইভেন্ট সাবস্ক্রাইব করার জন্য আপনার স্ট্যাটাস ওয়েবহুক কনফিগার করুন। ব্যাচ রিকনসিলিয়েশন চালানোর আগে যাচাই করুন যে আপনার অভ্যন্তরীণ রিপোর্টিং সিস্টেমগুলো কিউতে থাকা ফ্রেমগুলোকে চূড়ান্ত বিল করা ইউনিটের পরিবর্তে মুলতুবি হোল্ড হিসেবে শ্রেণীবদ্ধ করছে।

IOSOR সারাংশ

এই নির্দেশিকাটি প্রতিষ্ঠা করেছে যে একটি বার্তা ফ্রেম কিউতে রাখা নেটওয়ার্ক ডেলিভারি ক্ষমতা সংরক্ষণের জন্য একটি অনুমোদন হোল্ড ট্রিগার করে, তাৎক্ষণিক লেজার ডেবিট নয়। কিউতে থাকা পে-লোডগুলোকে সম্পূর্ণ কার্যকর করা ডিসপাচ হিসেবে বিবেচনা করলে কৃত্রিম ব্যালেন্স শেষ হয়ে যাওয়া, ভুল বিলিং রিকনসিলিয়েশন এবং আপস্ট্রিম নেটওয়ার্ক জট বা রিট্রাইয়ের সময় অকাঙ্ক্ষিত ব্যালেন্স হ্রাস পায়। আপনার আর্কিটেকচারের মধ্যে সক্রিয় কিউ হোল্ডগুলোকে চূড়ান্ত লেজার কমিট থেকে আলাদা রাখুন এবং খরচ অ্যাকাউন্টিংয়ের জন্য স্পষ্ট চূড়ান্ত ডিসপাচ ওয়েবহুক বা ডিএলআর ইভেন্টের ওপর নির্ভর করুন। বার্তাগুলো কিউতে থাকা অবস্থায় ব্যবহারকারীর ব্যালেন্স ডেবিট করবেন না বা চূড়ান্ত ইনভয়েস আইটেম তৈরি করবেন না এবং জীবনচক্র অবস্থা হ্যান্ডলারের মাধ্যমে স্বয়ংক্রিয়ভাবে রিলিজ হওয়া টাইম-আউট ফ্রেমগুলোর জন্য কখনই ম্যানুয়াল লেজার সংশোধন করবেন না।