جب ایمبیڈڈ ٹیننٹ کیپ کو ارسال روکنا ضروری ہو

ایمبیڈڈ ملٹی ٹیننٹ SaaS کو فیئر شیئر کیپس کی ضرورت ہوتی ہے تاکہ ایک زیادہ ٹریفک والا ٹیننٹ مشترکہ پری پیڈ بیلنس کو ختم نہ کرے یا دوسرے صارفین کو متاثر نہ کرے۔ ایک ایسی کیپ جو صرف ڈیش بورڈ پر وارننگ دکھاتی ہے جبکہ API سبمٹ قبول کرتا رہتا ہے وہ صرف دکھاوا ہے۔ جب ٹیننٹ حد تک پہنچ جائے تو اس ٹیننٹ کے لیے ارسال کو واضح پروڈکٹ ایرر اور میپ شدہ نان سکسیس API اسٹیٹس کے ساتھ روکنا ضروری ہے۔ جعلی ڈیلیورڈ 200 جوابات ڈیٹا کی مطابقت کو خراب کرتے ہیں اور غلط استعمال کو فروغ دیتے ہیں۔

کیپس ISV پروڈکٹ لیئر میں ہوتے ہیں — یہ پارٹنر سب ٹیننٹ ریٹ لمٹس کا متبادل نہیں ہیں اور نہ ہی کیو میں خاموش ڈراپ ہیں۔ سچی روک تھام کا مطلب ہے: SaaS UI معطل یا محدود دکھائے، ایمبیڈ سروس اس ٹیننٹ ID کے لیے نئے سبمٹ سے انکار کرے، اور آپریشنز ٹیم دیکھ سکے کہ کس نے حد کو چھوا ہے۔

پائلٹ ٹریفک سے پہلے روکنے کا معاہدہ لکھیں: کیپ یونٹ (پیغامات / خرچ / دن)، ری سیٹ ونڈو، کون حد بڑھا سکتا ہے، اور آخری صارف کیا دیکھتا ہے۔

کیپ تک پہنچنے کا مطلب ہے سبمٹ سے انکار، نہ کہ ہمیشہ نرم تنبیہ

نرم تنبیہات صرف ابتدائی الرٹ ہیں۔ سخت حد پر، ایمبیڈ سروس ٹیننٹ کیپڈ ایرر واپس کرتی ہے اور نئی درخواستوں کے لیے میسجنگ API کو کال نہیں کرتی۔ پہلے سے جاری پیغامات مکمل ہو سکتے ہیں؛ نئے OTP اور مہمات ری سیٹ یا منظور شدہ حد میں اضافے کا انتظار کریں گے۔

ٹیننٹ ID، کیپ رول اور ٹائم اسٹیمپ کے سات.

کیپ شدہ راستے پر کبھی بھی کامیابی سے ڈیلیورڈ ظاہر نہ کریں

خاموش ڈراپ اور جعلی 200 جواب کیو اوور فلو کی طرح.

پروڈکٹ کیپس کو والیٹ کی روک حدوں کے ساتھ ہم آہنگ کریں

ایک ٹیننٹ اپنی فیئر شیئر حد سے نیچے ہو سکتا ہے جبکہ ISV والیٹ کی روک حد پہلے ہی سرخ ہو چکی ہو۔ تب پورا ایمبیڈ راستہ معطل ہو جاتا ہے — نہ صرف زیادہ ٹریفک والا ٹیننٹ۔ والیٹ کا گرین ہونا اس ٹیننٹ کو چھوٹ نہیں دیتا جس نے پہلے ہی اپنا حصہ ختم کر دیا ہے۔ ایک اسٹیٹس زبان استعمال کریں: ٹیننٹ کیپڈ بمقابلہ اکاؤنٹ معطل بمقابلہ دونوں۔

حد بڑھانے کی درخواستوں کے لیے ایک نامزد.

زیادہ ٹریفک والے ٹیننٹ کے ساتھ اسٹیجنگ میں روکنے کا تجربہ کریں

پروڈکشن سے پہلے، اسٹیجنگ میں ٹیسٹ کریں: ایک ٹیننٹ OTP بھیجتا ہے یہاں تک کہ کیپ ٹرپ ہو جائے، باقی ٹیننٹس ارسال جاری رکھتے ہیں، اور ایکسپورٹ میں بغیر کسی جعلی ڈیلیوری کے انکار کی سطریں نظر آتی ہیں۔ اگر دوسرے ٹیننٹس رک جاتے ہیں تو کیپ کا اسکوپ غلط ہے۔ اگر زیادہ ٹریفک والا ٹیننٹ اب بھی گرین ٹک دیکھتا ہے تو روکنے کا نظام خراب ہے۔

متعلقہ آپریشنز کے راستے

• ملٹی ٹیننٹ اکاؤنٹس میں ریٹ لمٹس کا محفوظ نفاذ
• کیو اوور ف্লো: رکیں، سাইলمنٹ ڈراپ نہ کریں
• پروڈکشن ٹریفک سے پہلے والیٹ کی روک حدیں

IOSOR کے ساتھ شروع کریں

IOSOR کنسول کھولیں اور اپنے سب ٹیننٹ فیئر شیئر کیپس کو اس طرح ترتیب دیں کہ حد پوری ہونے پر سبمٹ گیٹ پر سخت انکار کو نافذ کیا جا سکے۔ اپنے API رسپانس میپنگ کو کنفیگر کریں تاکہ محدود ٹیننٹس کو قبول شدہ پے لوڈ کے بجائے ایک واضح اسٹیٹس کی خرابی موصول ہو۔ ایک شور مچانے والے ٹیننٹ کے ساتھ اسٹیجنگ ٹیسٹ چلائیں تاکہ یہ یقینی بنایا جا سکے کہ بہن بھائی کا ٹریفک آزادانہ طور پر بہتا ہے جبکہ محدود سبمٹس کو واضح انکار لاگ اندراجات کے طور پر ریکارڈ کیا جاتا ہے۔

IOSOR خلاصہ

جب ایک واحد سب ٹیننٹ میں اچانک اضافہ ہوتا ہے تو نرم انتباہات نیچے کی قطاروں کی حفاظت میں ناکام ہوجاتے ہیں۔ اس آپریشنل گائیڈ نے ثابت کیا کہ فیئر شیئر کیپس کو سبمٹ گیٹ پر فوری انکار کے طور پر کام کرنا چاہیے، جو ٹیننٹ کی حد کے ہٹ اور گلوبل والیٹ اسٹاپ لائنوں کے درمیان واضح علیحدگی کو برقرار رکھتا ہے۔

اپنی ایپلیکیشن لیئر کو الگ الگ محدود اسٹیٹس کے جوابات ضرور واپس کریں تاکہ سب ٹیننٹس مناسب طریقے سے حد میں اضافے کی درخواست کر سکیں۔ محدود کوششوں کے لیے جعلی 200 قبولیت یا ڈیلیور شدہ DLRs واپس نہ کریں، کیونکہ جھوٹی کامیابی کو ظاہر کرنا حقیقی ترسیل کی خرابیوں کو چھپاتا ہے اور ٹیننٹ کی قابلِ تدقیق کو برباد کرتا ہے۔