3.14 ملٹی ٹیننسی اور SaaS فن تعمیر

جائزہ اور محرکات

ملٹی ٹیننسی اپنے سافٹ ویئر کا ایک انسٹینس یوں چلانے کا عمل ہے کہ وہ بہت سے الگ گاہکوں کی ایک ساتھ خدمت کرے، ہر گاہک کے ڈیٹا اور ترتیب کو منطقی طور پر الگ رکھتے ہوئے جبکہ وہ ایک ہی کوڈ اور اکثر ایک ہی انفراسٹرکچر بانٹتے ہیں۔ ہر گاہک ایک ٹیننٹ ہے۔ یہی ایک خیال software as a service (SaaS) کا معاشی انجن ہے، وہ ماڈل جس میں آپ انسٹال کرنے کے لیے نقل کی بجائے چلتی ایپلیکیشن تک رسائی بیچتے ہیں۔ جب ایک ہزار ٹیننٹ ایک ہی تعیناتی بانٹیں تو آپ ایک بار پیچ کرتے ہیں، ایک نظام کی پیمائش کرتے ہیں، اور اگلے گاہک کی حاشیائی لاگت صفر کے قریب پہنچتی ہے۔ اسی لیے اچھی طرح بنی ملٹی ٹیننٹ پروڈکٹ ایک ہی کوڈ بیس سے دو افراد کے اسٹارٹ اپ اور لاکھ نشستوں کے انٹرپرائز دونوں کی خدمت کر سکتی ہے، اور اسی لیے آپ کا چنا ٹیننسی ماڈل برسوں تک آپ کے منافع، آپ کی سلامتی کی حیثیت، اور آپ کے آپریشنل بوجھ کو شکل دیتا ہے۔

بڑی ٹیموں کے لیے داؤ لاگت سے گہرے ہیں۔ ملٹی ٹیننسی آپ کے فن تعمیر کے مرکز میں سخت تقاضا رکھتی ہے: ٹیننٹ A کو ٹیننٹ B کا ڈیٹا کبھی نظر نہیں آنا چاہیے، کسی بگ، ریس، یا غلط ترتیب کے تحت نہیں۔ ایک واحد ٹیننٹوں کے پار لیک کمپنی ختم کر سکتا ہے۔ ساتھ ہی بانٹنے کا پورا مقصد کارکردگی ہے، اس لیے ہر ڈیزائن کا فیصلہ مضبوط علیحدگی (زیادہ محفوظ، زیادہ مہنگی) اور گھنی بانٹ (سستی، زیادہ خطرناک) کے طیف پر بیٹھتا ہے۔ اسے درست کرنا اس پروڈکٹ کے درمیان فرق ہے جو شائستگی سے پیمائش کرتی ہے اور جو یا تو انفراسٹرکچر پر آپ کو دیوالیہ کرتی ہے یا سرخیوں میں لے آتی ہے۔ یہ باب کلاؤڈ فن تعمیر (باب 3.11) پر بنتا ہے، ڈیٹا کے فن تعمیر (باب 3.4) اور کلاؤڈ سلامتی (باب 4.3) پر بھاری انحصار کرتا ہے، اور وسعت پذیری اور لچک (باب 3.5) اور لاگت کی نسبت (باب 9.4) سے جڑتا ہے۔

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

بنیادی اصول

علیحدگی طیف ہے، سوئچ نہیں۔ Silo، pool، اور bridge ماڈلز کارکردگی کو علیحدگی کے بدلے تجارت کرتے ہیں؛ فی درجہ اور فی وسیلہ چنیں، سب کے لیے ایک بار نہیں۔
ٹیننٹ کا سیاق مقدس ہے۔ ہر درخواست، سوال، لاگ لائن، اور پس منظر کے کام کو ٹیننٹ کا شناخت کنندہ لے جانا چاہیے، اور ڈیٹا کی ہر رسائی اس سے دائرہ بند ہونی چاہیے۔
ٹیننٹوں کے پار لیک سب سے اہم ناکامی ہے۔ یوں ڈیزائن کریں کہ ایک غائب فلٹر دوسرے ٹیننٹ کا ڈیٹا ظاہر نہ کر سکے؛ گہرائی میں دفاع، ایک WHERE شق نہیں۔
شور مچانے والے ہمسائے فن تعمیر کا مسئلہ ہیں۔ کوٹوں اور انصاف کے بغیر ایک بھاری ٹیننٹ سب کو بگاڑتا ہے؛ ہونے سے پہلے اس کی منصوبہ بندی کریں۔
فی ٹیننٹ ترتیب پیمائش کرتی ہے؛ فی ٹیننٹ کوڈ نہیں۔ پروڈکٹ کو ڈیٹا اور فلیگز سے موڑیں، فورکس سے نہیں۔
ٹیننٹ کا زندگی کا چکر پروڈکٹ کا فیچر ہے۔ آن بورڈنگ، فراہمی، آف بورڈنگ، اور ڈیٹا کی برآمد اولین درجے کی، خودکار، اور قابل آڈٹ ہونی چاہئیں۔
جس کی نسبت نہ کر سکیں اسے منظم نہیں کر سکتے۔ مشاہدہ پذیری اور لاگت ٹیننٹ کے حساب سے کاٹی جانی چاہیے، ورنہ آپ اعتبار اور منافع دونوں پر اندھے اڑتے ہیں۔

سفارشات

علیحدگی بمقابلہ کارکردگی کے طیف کے ساتھ، فی درجہ ٹیننسی ماڈل چنیں

تین ماڈل طیف کو لنگر انداز کرتے ہیں۔ silo (مخصوص) ماڈل میں ہر ٹیننٹ کو اپنا الگ تھلگ اسٹیک ملتا ہے: الگ کمپیوٹ، الگ ڈیٹا بیس، کبھی الگ اکاؤنٹ یا نیٹ ورک۔ علیحدگی سب سے مضبوط ہے اور بگ کے دھماکے کا دائرہ ایک ٹیننٹ ہے، مگر آپ فی گاہک بیکار صلاحیت کی ادائیگی کرتے اور بہت سی نقلیں چلاتے ہیں۔ pool (مشترک) ماڈل میں تمام ٹیننٹ ایک ہی کمپیوٹ اور ڈیٹا بیس بانٹتے ہیں، صرف منطق اور ٹیننٹ کے شناخت کنندہ سے الگ۔ کارکردگی سب سے اونچی ہے اور ٹیننٹ کی حاشیائی لاگت صفر کے قریب ہے، مگر علیحدگی اب مکمل طور پر آپ کے کوڈ کے درست ہونے پر منحصر ہے۔ bridge (ہائبرڈ) ماڈل دونوں کو ملاتا ہے: فی ٹیننٹ ڈیٹا بیس کے ساتھ مشترک کمپیوٹ، یا چھوٹے ٹیننٹس کے لیے مشترک پول اور بڑے یا ضابطے کے پابند کے لیے مخصوص silos۔

پوری پروڈکٹ کے لیے ایک ماڈل نہ چنیں۔ درست جواب عموماً bridge ہے جو آپ کے قیمتوں کے درجوں سے ملتا ہے۔ چھوٹے ٹیننٹس کی لمبی دم کو موثر مشترک پول میں رکھیں جہاں ان کی معاشیات کام کرتی ہے۔ انٹرپرائز گاہکوں کے لیے پریمیم درجے کے طور پر مخصوص یا واحد ٹیننٹ تعیناتی پیش کریں جو علیحدگی اور معاہداتی ضمانتوں کی ادائیگی کریں گے۔ تقسیم کو فن تعمیر کے فیصلے کے ریکارڈ (باب 3.11) کے طور پر لکھیں، کیونکہ “کون سے ٹیننٹ کیا بانٹتے ہیں” ایسا دعویٰ ہے جس پر آپ کی سلامتی، سیلز، اور مالیات کی ٹیمیں سب انحصار کرتی ہیں۔

ڈیٹا کو جان بوجھ کر تقسیم کریں، اور ٹیننٹ کی حد بھولنا ناممکن بنائیں

ڈیٹا وہ جگہ ہے جہاں ملٹی ٹیننسی جیتی یا مرتی ہے، اس لیے تقسیم کے انتخاب کو بنیادی ڈیٹا کے فن تعمیر کا فیصلہ (باب 3.4) سمجھیں۔ تین حکمت عملیاں ٹیننسی ماڈلز کے متوازی ہیں۔ فی ٹیننٹ الگ ڈیٹا بیس سب سے مضبوط علیحدگی، آسان فی ٹیننٹ بیک اپ اور بحالی، اور سادہ ڈیٹا کی برآمد دیتا ہے، چلانے کو بہت سے ڈیٹا بیس اور پھیلانے کو اسکیما کی منتقلی کی قیمت پر۔ مشترک ڈیٹا بیس کے اندر فی ٹیننٹ الگ اسکیما درمیانی راستہ ہے: ایک سرور، منطقی علیحدگی، پھر بھی منتقل کرنے کو بہت سے آبجیکٹس۔ ٹیننٹ کالم سے کلید شدہ مشترک ٹیبلز، جہاں ہر قطار tenant_id رکھتی ہے، سب سے گھنا اور سستا، اور سب سے خطرناک ہے، کیونکہ اب ایک سوال جس میں ٹیننٹ کا فلٹر غائب ہو گاہکوں کے پار ڈیٹا لیک کرتا ہے۔

اگر آپ ٹیبلز بانٹتے ہیں تو ڈویلپرز کے فلٹر یاد رکھنے پر انحصار نہ کریں۔ ٹیننٹ کی حد ایسی تہہ میں نافذ کریں جسے بائی پاس نہ کیا جا سکے: ڈیٹا بیس کی row-level سلامتی جو سیشن کے ٹیننٹ کی بنیاد پر ہر سوال سے لازمی شرط جوڑے، ORM یا ڈیٹا تک رسائی کی تہہ جو ٹیننٹ کی شق خود بخود داخل کرے، یا دونوں۔ یہاں پیٹی اور بریسز درست ہیں۔ جیسے ٹیننٹ بڑھتے ہیں، ٹیننٹ کے حساب سے شارڈنگ فطری ہو جاتی ہے: ٹیننٹس کے گروہ مختلف ڈیٹا بیس شارڈز پر رکھیں تاکہ کوئی واحد انسٹینس سب کو نہ رکھے، جو ایک شارڈ کی ناکامی کے دھماکے کا دائرہ بھی محدود کرتا ہے اور آپ کو ماڈل بدلے بغیر بڑے ٹیننٹ کو اپنے شارڈ پر منتقل کرنے دیتا ہے۔

ٹیننٹ کا سیاق ہر جگہ پھیلائیں، اور ٹیننٹوں کے پار لیک کے خلاف گہرائی میں دفاع کریں

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

ٹیننٹوں کے پار علیحدگی کو گہرائی میں دفاع کے ساتھ سلامتی کی خاصیت سمجھیں، اور تفصیلات باب 4.3 کو سونپیں۔ کم از کم استحقاق کا اصول لاگو کریں تاکہ سمجھوتا شدہ جزو بھی صرف وہ ٹیننٹ پہنچ سکے جس کے لیے وہ کام کر رہا ہے۔ اجازت کے فیصلوں کے لیے ٹیننٹ کا شناخت کنندہ کلائنٹ کے کنٹرول والے ان پٹ سے کبھی قبول نہ کریں؛ اسے تصدیق شدہ شناخت سے اخذ کریں۔ کیشز، آبجیکٹ اسٹوریج کے سابقے، اور تلاش کے انڈیکس ٹیننٹ کے نام کی جگہ میں رکھیں تاکہ کلید کا ٹکراؤ حد پار نہ کر سکے۔ پھر حد کو جان بوجھ کر ٹیسٹ کریں: خودکار ٹیسٹ جو دعویٰ کریں کہ ٹیننٹ A کی اسناد ٹیننٹ B کے ریکارڈ نہیں پڑھ سکتیں، اور وقتاً فوقتاً ریڈ ٹیم کی مشقیں جو ٹیننٹ سے باہر نکلنے کی کوشش کریں۔ آپ کے ٹیسٹ سوٹ کو ملا لیک بگ ہے؛ گاہک کو ملا لیک بحران ہے۔

کوٹوں، شرح کی حدوں، اور انصاف سے شور مچانے والے ہمسایوں کو قابو کریں

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

نفاذ کو اپنے ٹیننسی ماڈل سے ملائیں۔ مشترک پول میں کوٹے اور انصاف بنیادی دفاع ہیں، اس لیے ان میں سرمایہ لگائیں۔ ایسے ٹیننٹ کے لیے جس کا بوجھ منصفانہ بانٹ کی برداشت سے واقعی بڑھ جائے، جواب اکثر انہیں پول سے نکال کر bridge یا silo تعیناتی میں ترقی دینا ہے، جو ایسا فیچر ہے جسے آپ بیچ سکتے ہیں، ناکامی نہیں۔ اسے اپنے وسعت پذیری اور لچک کے کام (باب 3.5) سے جوڑیں: بوجھ گرانا، سرکٹ بریکرز، اور بیک پریشر سب کو ٹیننٹ سے باخبر ہونا چاہیے تاکہ ایک ٹیننٹ کا اضافی بوجھ گرانا پورے نظام کو بگاڑنے کی بجائے باقیوں کی حفاظت کرے۔

ٹیننٹس کو ڈیٹا سے ترتیب دیں، اپنے کوڈ کے فورکس سے نہیں

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

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

ٹیننٹ کے زندگی کے چکر کو خودکار، قابل مشاہدہ، اور لاگت کی نسبت والا بنائیں

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

ہر چیز فی ٹیننٹ آلہ دار بنائیں۔ لاگز، ٹریسز، اور میٹرکس کو ٹیننٹ کے شناخت کنندہ سے ٹیگ کریں تاکہ آپ سیکنڈوں میں “کیا یہ بندش تمام ٹیننٹس کی ہے یا ایک کی؟” اور “کون سا ٹیننٹ یہ لاگت چلا رہا ہے؟” کا جواب دے سکیں۔ انفراسٹرکچر کی لاگت ٹیننٹس کو منسوب کریں تاکہ آپ فی گاہک اپنا حقیقی منافع جانیں اور اس ٹیننٹ کو دیکھ سکیں جس کا استعمال اسے موجودہ قیمت پر غیر منافع بخش بناتا ہے (باب 9.4)۔ ٹیننٹ سے باخبر مشاہدہ پذیری اور لاگت کی نسبت ملٹی ٹیننسی کو سیاہ ڈبے سے ایسے نظام میں بدلتی ہے جو آپ دراصل چلا اور قیمت لگا سکتے ہیں۔

سمجھوتے: فوائد اور نقصانات

ٹیننسی ماڈل	فوائد	نقصانات
Silo (فی ٹیننٹ مخصوص اسٹیک)	مضبوط ترین علیحدگی، سب سے چھوٹا دھماکے کا دائرہ، آسان فی ٹیننٹ تعمیل اور برآمد، سادہ شور مچانے والے ہمسایوں کی کہانی	سب سے زیادہ لاگت، فی ٹیننٹ بیکار صلاحیت، چلانے اور پیچ کرنے کو بہت سی نقلیں
Pool (مکمل مشترک)	سب سے کم حاشیائی لاگت، سب سے گھنی پیکنگ، پیمائش اور اپ گریڈ کے لیے ایک نظام	علیحدگی مکمل طور پر کوڈ کی درستگی پر منحصر، بدترین شور مچانے والے ہمسایوں کا خطرہ، فی ٹیننٹ برآمد اور حذف مشکل ترین
Bridge (ہائبرڈ، درجہ دار)	چھوٹے ٹیننٹس کے لیے موثر، بڑوں کے لیے مخصوص علیحدگی، قیمتوں سے ملتا ہے	بنانے اور چلانے کو زیادہ ماڈلز، درجوں کے درمیان ترقی کا راستہ برقرار رکھنا
مشترک DB، مشترک اسکیما (ٹیننٹ کالم)	سستا ترین ذخیرہ، ایک منتقلی، سادہ ترین آپریشنز	ایک غائب فلٹر ڈیٹا لیک کرتا ہے؛ پشت پناہی کے طور پر row-level سلامتی چاہیے
مشترک DB، فی ٹیننٹ اسکیما	منطقی علیحدگی، ایک سرور، معقول برآمد	بہت سے اسکیما آبجیکٹس، منتقلیاں پھیلتی ہیں، فی سرور پیمائش کی حدیں
فی ٹیننٹ ڈیٹا بیس	مضبوط ڈیٹا کی علیحدگی، فی ٹیننٹ بیک اپ اور برآمد	بہت سے ڈیٹا بیس، منتقلی کا پھیلاؤ، زیادہ لاگت

مرکزی کھنچاؤ علیحدگی بمقابلہ کارکردگی ہے، اور یہ ہر قطار میں چلتا ہے۔ گھنی بانٹ آپ کے منافع کو ضرب دیتی ہے اور اسی حرکت میں آپ کے خطرے کو ضرب دیتی ہے؛ مضبوط علیحدگی حقیقی فی ٹیننٹ لاگت پر حفاظت اور سادگی خریدتی ہے۔ حل ایک قطب چننا نہیں بلکہ ہر ٹیننٹ کو طیف پر جان بوجھ کر رکھنا ہے، عموماً درجے کے حساب سے: چھوٹے ٹیننٹس کو گھنے پیک کریں جہاں معاشیات تقاضا کرے اور خطرہ محدود ہو، بڑے اور ضابطے کے پابند ٹیننٹس کو الگ کریں جہاں وہ ادائیگی کریں گے اور دھماکے کا دائرہ چھوٹا ہونا چاہیے۔ پھر گھنے سرے کو نافذ شدہ ٹیننٹ کی حد سے محفوظ بنائیں، اور الگ تھلگ سرے کو خودکاری سے سستا بنائیں، تاکہ کوئی قطب سادہ ورژن جتنا نہ دکھے۔

اپنی ٹیم کے ساتھ بحث کے سوالات

اگر کل ایک ٹیننٹ کی حد کا فلٹر غائب ہو تو کیا گاہک کو دوسرے گاہک کا ڈیٹا نظر آئے گا؟ یہ وہ سوال ہے جو قابل دفاع ملٹی ٹیننٹ پروڈکٹ کو انتظار کرتے حادثے سے الگ کرتا ہے۔ ایماندار ٹیسٹ یہ ہے کہ حقیقی پڑھنے کے راستے کا سراغ لگائیں اور پوچھیں ٹیننٹ کی حد کیا نافذ کرتا ہے: کیا ڈویلپر کی لکھی ایک WHERE شق ہے، یا کوئی پشت پناہی ہے جیسے ڈیٹا بیس کی row-level سلامتی یا ڈیٹا تک رسائی کی تہہ جو ہر حال میں حد داخل کرتی ہے؟ اپنے حقیقی سوال کے راستے، اپنے پس منظر کے کام، اور اپنے کیش لائیں، کیونکہ لیک تقریباً ہمیشہ اس غیر ہم وقت کونے میں چھپتا ہے جسے کسی نے دائرہ بند نہیں کیا۔ آپ کو ایسے ٹیسٹ کے نتائج بھی لانے چاہئیں جو جان بوجھ کر ٹیننٹ A کا سیشن استعمال کر کے ٹیننٹ B کے ریکارڈ مانگے اور انکار کا دعویٰ کرے۔ اگر حد اکیلی انسانی چوکسی پر ٹکی ہو تو آپ کے پاس پوشیدہ خلاف ورزی ہے، اور اصلاح (گہرائی میں دفاع) بیک لاگ کے اوپر جانی چاہیے۔
ہر گاہک کا درجہ دراصل کون سا ٹیننسی اور ڈیٹا کی تقسیم کا ماڈل استعمال کرتا ہے، اور کیا وہ اس سے میل کھاتا ہے جو ہم نے انہیں بیچا؟ بہت سی ٹیمیں ڈیفالٹ سے واحد ماڈل کی طرف بھٹکتی ہیں، پھر دریافت کرتی ہیں کہ ان کی قیمتیں اور فن تعمیر اختلاف کرتے ہیں: انٹرپرائز گاہکوں سے علیحدگی کا وعدہ کیا گیا تھا جو مشترک پول نہیں دیتا، یا چھوٹے گاہک مہنگے مخصوص اسٹیکس میں بیٹھے ہیں جو منافع برباد کرتے ہیں۔ ہر درجے کو اس کے حقیقی ماڈل سے نقشہ بنائیں (silo، pool، یا bridge؛ فی ٹیننٹ ڈیٹا بیس، اسکیما، یا مشترک ٹیبل) اور اسے ان معاہداتی ڈیٹا کی ضمانتوں کے ساتھ رکھیں جو آپ کی سیلز ٹیم دیتی ہے۔ جہاں وہ مختلف ہوں آپ کے پاس یا تعمیل کا خطرہ ہے یا لاگت کا مسئلہ، اور دونوں کو گاہک یا آڈیٹر کے ڈھونڈنے سے پہلے سامنے لانا قابل قدر ہے۔ لانے کی شہادت درجے سے ماڈل کا نقشہ، فی ٹیننٹ لاگت، اور آپ کے انٹرپرائز معاہدوں کی اصل زبان ہے۔
جب بڑے ٹیننٹ کا بوجھ اچھلتا ہے تو اور کس کو محسوس ہوتا ہے، اور ہمارا منصوبہ کیا ہے؟ مشترک پول میں جواب اکثر “سب کو” ہوتا ہے، اور ٹیمیں اکثر یہ جانتی نہیں جب تک واقعہ اسے واضح نہ کر دے۔ سوچیں کہ جب آپ کا سب سے بڑا ٹیننٹ بلک امپورٹ چلاتا ہے یا ٹریفک کا اضافہ پاتا ہے تو کیا ہوتا ہے: کیا فی ٹیننٹ کوٹے اور منصفانہ شیڈولنگ اسے قابو کرتے ہیں، کیا بوجھ گرانا ہمسایوں کی حفاظت کرتا ہے، یا پورا نظام ساتھ بگڑتا ہے؟ بوجھ کا ڈیٹا اور اپنے آخری شور مچانے والے ہمسائے کے واقعے کی کہانی لائیں، کیونکہ جو ٹیننٹ آپ کو نقصان دیتا ہے وہ عموماً وہ ہوتا ہے جس کا آپ نام لے سکیں۔ جواب شرح کی حد میں آپ کی سرمایہ کاری اور آپ کی درجہ بندی کی حکمت عملی دونوں کو شکل دے، کیونکہ منصفانہ بانٹ سے بڑھنے والے ٹیننٹ کا سب سے صاف حل انہیں bridge یا مخصوص تعیناتی میں ترقی دینا ہے جس کی آپ قیمت لگا سکیں۔
اگر کل ٹیننٹ آف بورڈ ہو تو کیا ہم انہیں صاف برآمد دے سکتے ہیں اور ثابت کر سکتے ہیں کہ ہر نشان حذف کیا، یا ہم بھاگ دوڑ کر رہے ہوں گے؟ آف بورڈنگ ٹیننٹ کے زندگی کے چکر کا وہ حصہ ہے جسے ٹیمیں نظر انداز کرتی ہیں جب تک معاہدے سے نکلنے کی شق یا رازداری کے قانون کی درخواست معاملہ مجبور نہ کرے، اور تب تک مشترک اسکیما نکالنا اور حذف تکلیف دہ بنا چکا ہوتا ہے۔ بڑی ٹیم کے لیے خطرہ مرکب ہوتا ہے، کیونکہ ٹیننٹ کا ڈیٹا بنیادی ڈیٹا بیس، کیشز، آبجیکٹ اسٹوریج، تلاش کے انڈیکس، بیک اپس، اور تجزیات کی پائپ لائنز میں بکھرا ہے، اور ہر ایک کو قابل استعمال فارمیٹ میں برآمد اور پھر ثابت شدہ طور پر صاف ہونا ہے۔ متصادم غور حقیقی ہیں: گھنی مشترک ٹیبلز جو آپ کو سستا ذخیرہ دیتی ہیں ٹھیک وہی ہیں جو فی ٹیننٹ نکالنا اور حذف سب سے مشکل بناتی ہیں، اس لیے ذخیرے کی تہہ پر خریدی گئی کارکردگی آپ باہر نکلنے پر واپس ادا کر سکتے ہیں۔ حقیقی ٹیننٹ پر آف بورڈنگ کا زندہ مظاہرہ، ٹیننٹ کا ڈیٹا رکھنے والے ہر اسٹور کی فہرست، اور وہ شہادت لائیں جو آپ دکھائیں گے کہ حذف واقعی ہوا۔ انٹرپرائز اور سرکاری ٹیننٹس کے لیے برآمد تصدیق شدہ اور حذف ثابت ہونا چاہیے تاکہ عوامی ریکارڈ اور رازداری کے قوانین پورے ہوں، اس لیے حذف کے غائب راستے کو تعمیل کے نقص کے طور پر ابھی بند کریں، نہ کہ فیچر جو گاہک کے جانے پر جوڑا جائے۔
انفرادی گاہکوں کے لیے ہمارے کوڈ کے راستے میں پہلے ہی کتنی ایک بار کی خاص صورتیں ہیں، اور وہ لکیر کہاں ہے جو ہم پار نہیں کریں گے؟ فی ٹیننٹ کوڈ کے فورکس وہ خاموش طریقہ ہیں جس سے SaaS کا کاروبار ایک پروڈکٹ نہیں رہتا اور ایک نام کے نیچے بہت سی پروڈکٹس بن جاتا ہے، جہاں ہر تبدیلی کو ہر خاص صورت کے مقابل ٹیسٹ ہونا ہے اور گاہک جوڑنے کے ساتھ رفتار گھٹتی ہے۔ کھنچاؤ یہ ہے کہ حقیقی ضرورت والے بڑے گاہک کو انکار کرنا مشکل ہے، اور کوڈ کے راستے میں برانچ ترتیب کی سطح بنانے سے تیز لگتی ہے، اس لیے خاص صورتیں ایک ایک معقول استثنا سے جمع ہوتی ہیں۔ ایماندار فہرست لائیں: کوڈ بیس میں گاہکوں کے نام اور درجے سے مخصوص برانچوں کے لیے grep کریں، انہیں گنیں، اور اندازہ لگائیں کہ ہر ایک غیر متعلق تبدیلی پر اضافی ٹیسٹ اور ریویو کی کتنی لاگت ڈالتی ہے۔ بحث کو اس تغیر کے درمیان پکی لکیر کھینچنی چاہیے جسے آپ اولین درجے کی ترتیب (فلیگز، استحقاق، توسیع کے نکات) کے طور پر ماڈل کرتے ہیں اور اس حقیقی حسب ضرورت کام کے درمیان جو آپ واحد ٹیننٹ پریمیم درجے کے لیے رکھتے ہیں جہاں اونچی قیمت آپریشنل لاگت پوری کرتی ہے۔ گہری حسب ضرورت مانگنے والے انٹرپرائز خریداروں کے لیے پائیدار جواب توسیع کے نکات ہیں جو ان کی منطق چلاتے ہیں آپ کی برانچ کیے بغیر، تاکہ بیڑے کے پار نظم و نسق اور آڈٹ قابل کنٹرول رہیں۔
کیا ہم فی ٹیننٹ بتا سکتے ہیں کہ واقعہ کس کو کتنی لاگت دے رہا ہے، اور کون سے گاہک اپنی موجودہ قیمت پر غیر منافع بخش ہیں؟ ملٹی ٹیننسی سیاہ ڈبے میں بدل جاتی ہے جس لمحے آپ کے لاگز، ٹریسز، میٹرکس، اور انفراسٹرکچر کی لاگت کا کوئی ٹیننٹ کا پہلو نہ ہو، کیونکہ پھر آپ نہیں جواب دے سکتے کہ بندش ایک ٹیننٹ کی ہے یا پورے بیڑے کی، اور آپ اس ٹیننٹ کا نام نہیں لے سکتے جس کا استعمال اسے معاہدے کی قیمت پر نقصان میں بناتا ہے۔ بڑی ٹیم کے لیے یہ نسبت وہ ہے جو پلیٹ فارم چلانے کو اس کا اندازہ لگانے سے الگ کرتی ہے، اور یہ براہ راست اعتبار کے ردعمل اور قیمتوں دونوں کو شکل دیتی ہے۔ غور آلہ دار بنانے کی لاگت اور cardinality کے خلاف کھنچتے ہیں: ہر چیز کو ٹیننٹ سے ٹیگ کرنا مفت نہیں، اور اونچی cardinality کے میٹرکس آپ کے مشاہدہ پذیری کے بجٹ پر دباؤ ڈالتے ہیں، اس لیے آپ جان بوجھ کر چنتے ہیں کہ فی ٹیننٹ کیا کاٹنا ہے اور کیا نمونہ لینا ہے۔ اپنی ٹیننٹ ٹیگنگ کی موجودہ کوریج، کلاؤڈ کا خرچ ایک ٹیننٹ کو منسوب کرنے والا حقیقی سوال، اور منافع کی ٹیبل لائیں جو آپ کو اپنے سب سے کم منافع بخش گاہک کا نام لینے دے۔ انٹرپرائز اور سرکاری ترتیبوں میں فی ٹیننٹ لاگت اور آڈٹ کے دائرے کی مشاہدہ پذیری chargeback، صلاحیت کی منصوبہ بندی، اور وہ آڈٹ کی حد بھی کھلاتی ہیں جس کی ہر ایجنسی یا کاروباری اکائی حقدار ہے، اس لیے ٹیننٹ کا پہلو آپریشنل کے ساتھ نظم و نسق کا تقاضا بھی ہے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ پہلے دن سے واحد مشترک پول بھیجیں اور اپنی کم یاب انجینئرنگ کی توجہ اس ایک چیز میں لگائیں جسے بعد میں دوبارہ نہیں لگایا جا سکتا: نافذ شدہ ٹیننٹ کی حد۔ row-level سلامتی کے ساتھ منظم Postgres، ہر ٹیبل پر tenant_id، اور کنارے پر حل ہوتا ٹیننٹ کا سیاق آپ کو آپریشنز کی ٹیم کے بغیر محفوظ کثافت خریدتے ہیں۔ قیاس آرائی سے silo کے درجے یا فی ٹیننٹ انفراسٹرکچر نہ بنائیں؛ bridge کا درجہ تب جوڑیں جب ادائیگی کرنے والا انٹرپرائز امکان علیحدگی کو اس کی لاگت کے قابل بنائے۔

چھوٹا کاروبار۔ مخصوص پلیٹ فارم کے ماہر کے بغیر اور تنگ بجٹ کے ساتھ اس پر انحصار کریں جو آپ کا کلاؤڈ اور فریم ورک پہلے سے دیتے ہیں بجائے علیحدگی کی مشینری خود بنانے کے۔ row-level سلامتی والے منظم ڈیٹا بیس، platform-as-a-service جو آپ کے لیے ٹیننٹ کی حد بناتی ہے، اور تصدیق فراہم کنندہ جو ٹیننٹ کی شناخت لے کر چلتا ہے عموماً ہاتھ سے بنائے مساوی سے سستے اور محفوظ ہیں۔ ملٹی ٹیننسی کو ہر تہہ پر خریدنے بمقابلہ بنانے کا فیصلہ سمجھیں، اور حسب ضرورت کام ٹیننٹ کی حد کے ٹیسٹوں کے لیے رکھیں جو صرف آپ لکھ سکتے ہیں۔

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

حکومت۔ خریداری، ڈیٹا کا مقام، اور عوامی جوابدہی ماڈل چلاتے ہیں۔ ہر ایجنسی کا ڈیٹا policy-as-code سے ملک کے اندر کے خطوں سے باندھیں، حساس یا اعلیٰ درجہ بندی کے بوجھ کو اپنی آڈٹ کی حد کے ساتھ الگ اکاؤنٹس میں silo کریں، اور ہر ایجنسی کو اس کا اپنا شناخت کا انضمام، برقراری کے اصول، اور آڈٹ کا نشان دیں تاکہ ایک ایجنسی کے آڈیٹرز کو دوسری کی سرگرمی کبھی نظر نہ آئے۔ آف بورڈنگ کو عوامی ریکارڈ اور رازداری کے قوانین پورے کرنے کے لیے تصدیق شدہ برآمد اور ثابت شدہ حذف پیدا کرنا چاہیے، اور آپ جو ٹیننسی کی ضمانتیں دستخط کرتے ہیں وہ ایسی ہوں جو آپ کا فن تعمیر واقعی نبھا سکے۔

مثالیں

اسٹارٹ اپ۔ پندرہ افراد کا اسٹارٹ اپ اپنی پروڈکٹ پہلے دن سے واحد مشترک پول کے طور پر بناتا ہے اور درست ہے۔ تمام ٹیننٹ ہر ٹیبل پر tenant_id کے ساتھ ایک منظم PostgreSQL ڈیٹا بیس بانٹتے ہیں، row-level سلامتی ڈیٹا بیس پر ٹیننٹ کی شرط نافذ کرتی ہے تاکہ بھولا ہوا فلٹر لیک نہ کر سکے، اور ایپلیکیشن کنارے پر سب ڈومین سے ٹیننٹ حل کرتی اور اسے ہر درخواست اور پس منظر کے کام سے گزارتی ہے۔ آن بورڈنگ خود خدمتی ہے: نیا سائن اپ اپنی ٹیننٹ کی قطار فراہم کرتا، ڈیفالٹس بھرتا، اور سیکنڈوں میں زندہ ہو جاتا ہے۔ دو انجینئر پورا پلیٹ فارم چلاتے ہیں کیونکہ چلانے کو ایک نظام ہے۔ جب ان کا پہلا حقیقی انٹرپرائز امکان مخصوص ڈیٹا بیس اور معاہداتی علیحدگی کی ضمانت مانگتا ہے تو وہ bridge کا درجہ جوڑتے ہیں: وہی کوڈ بیس، مگر اس ٹیننٹ کو اپنے شارڈ پر اپنا ڈیٹا بیس ملتا ہے، ایسی قیمت پر بیچا جو لاگت پوری کرے۔

بڑا ادارہ۔ بڑے مالیاتی اداروں کی خدمت کرنے والا SaaS فروخت کنندہ درجہ دار bridge فن تعمیر چلاتا ہے۔ ہزاروں چھوٹے اور درمیانے سائز کے گاہک علاقائی مشترک پولز میں رہتے ہیں، ٹیننٹ سے شارڈ شدہ، کوٹوں اور منصفانہ شیڈولنگ کے ساتھ جو شور مچانے والے ہمسایوں کو قابو میں رکھتی ہے۔ اعلیٰ ترین بینکاری کے گاہکوں کو الگ تھلگ کلاؤڈ اکاؤنٹس میں واحد ٹیننٹ تعیناتیاں ملتی ہیں، مخصوص ڈیٹا بیس، فی ٹیننٹ خفیہ نگاری کی چابیوں، اور ڈیٹا کے مقام اور علیحدگی کی معاہداتی ضمانتوں کے ساتھ جو ماسٹر معاہدے میں لکھی ہیں۔ پلیٹ فارم کی صلاحیت ٹیننٹ کو درجوں کے درمیان بغیر بندش کے منتقل کرتی ہے جب وہ بڑھتا ہے یا اس کی تعمیل کی ضروریات بدلتی ہیں۔ ہر ٹیننٹ کی لاگت ٹیگنگ سے منسوب ہے تاکہ مالیات ہر اکاؤنٹ پر حقیقی منافع جانے، اور ٹیننٹ سے ٹیگ شدہ مشاہدہ پذیری آن کال انجینئر کو سیکنڈوں میں بتانے دیتی ہے کہ الرٹ ایک ٹیننٹ کا ہے یا پورے بیڑے کا۔

حکومت۔ قومی پلیٹ فارم فراہم کنندہ بہت سی سرکاری ایجنسیوں کو الگ ٹیننٹس کے طور پر میزبانی کرتا ہے اور علیحدگی کو ترجیح نہیں بلکہ قانونی تقاضا سمجھتا ہے۔ ڈیٹا کے مقام کا قانون ہر ایجنسی کا ڈیٹا ملک کے اندر کے خطوں سے باندھتا ہے، policy-as-code سے نافذ جو ممنوعہ خطے میں ہر وسیلہ روکتا ہے (باب 3.11)۔ درجہ بندی ماڈل چلاتی ہے: حساس مواد سنبھالنے والی ایجنسیوں کو اپنی آڈٹ کی حد کے ساتھ الگ اکاؤنٹس میں مکمل silo تعیناتیاں ملتی ہیں، جبکہ کم درجہ بندی کے بوجھ منظم پول بانٹتے ہیں۔ ہر ایجنسی اپنا ٹیننٹ ہے جس کا اپنا شناخت کا انضمام، اپنی برقراری اور برآمد کے اصول، اور اس کی حد کا دائرہ بند آڈٹ کا نشان ہے، تاکہ ایک ایجنسی کے آڈیٹرز کو دوسری کی سرگرمی کبھی نظر نہ آئے۔ آف بورڈنگ تصدیق شدہ ڈیٹا کی برآمد اور ثابت شدہ حذف پیدا کرتی ہے، کیونکہ ریکارڈ عوامی ریکارڈ اور رازداری کے قوانین کے تابع ہیں۔

کاروباری جواز: محرکات، ROI اور TCO

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

واپسی تین جگہ ظاہر ہوتی ہے: آپریشنل لیوریج (ایک ٹیم پورا بیڑا چلاتی ہے)، تیز ترسیل (اصلاح ہر ٹیننٹ تک ایک ساتھ پہنچتی ہے، اس لیے گاہک جوڑنے سے رفتار نہیں گھٹتی)، اور قیمتوں کے اختیارات (لمبی دم کے لیے مشترک منصوبہ اور انٹرپرائزز کے لیے پریمیم الگ تھلگ منصوبہ، دونوں ایک کوڈ بیس سے)۔ انہیں ان لاگتوں کے مقابل رکھیں جو آپ کو ایمانداری سے فنڈ کرنی ہیں: نافذ شدہ ٹیننٹ کی علیحدگی، کوٹے، زندگی کے چکر کی خودکاری، اور فی ٹیننٹ مشاہدہ پذیری بنانے کی انجینئرنگ، اور حد کو برقرار رکھنے کا نظم۔ غلط ہونے کی لاگت غیر متناسب اور سنگین ہے، کیونکہ ایک ٹیننٹوں کے پار ڈیٹا کی خلاف ورزی ضابطے کے جرمانے، بڑے پیمانے پر گاہکوں کے جانے، اور ساکھ کا نقصان لا سکتی ہے جو بانٹ سے آپ کے بچائے انفراسٹرکچر کو بونا کر دے۔ قیادت کے لیے دلیل کو اوپر منافع اور پیمانے کے طور پر اور نیچے وجودی خطرے کے طور پر پیش کریں۔ سروس لیول معاہدے اور معاہداتی ڈیٹا کی ضمانتوں کو اس ٹیننسی ماڈل سے لنگر انداز کریں جو آپ واقعی پہنچا سکتے ہیں، کیونکہ وہ وعدہ جو آپ کا فن تعمیر نہ نبھا سکے ذمہ داری ہے، سودا نہیں۔

ضد نمونے اور خامیاں

رواج سے ٹیننٹ کی حد۔ ڈیٹا بیس کی سطح یا ڈیٹا تک رسائی کی تہہ کی پشت پناہی کے بغیر ہر سوال پر ٹیننٹ کا فلٹر یاد رکھنے کے لیے ڈویلپرز پر انحصار؛ ایک غلطی خلاف ورزی ہے۔
کلائنٹ کے فراہم کردہ ٹیننٹ کے شناخت کنندہ پر بھروسہ۔ اجازت کے لیے تصدیق شدہ شناخت سے اخذ کرنے کی بجائے درخواست کے ان پٹ سے ٹیننٹ قبول کرنا، جو کال کرنے والے کو دوسرے کا ڈیٹا مانگنے دیتا ہے۔
بغیر حد کا پس منظر کا کام۔ کام، کیش، webhooks، اور برآمدات جو ٹیننٹ کا سیاق کھو دیتے ہیں کیونکہ کسی نے صرف ہم وقت درخواست کا راستہ دائرہ بند کیا۔
فی ٹیننٹ کوڈ کے فورکس۔ بڑے گاہک کو کوڈ کے راستے میں خاص صورت بنانا جب تک آپ ایک نام کے نیچے بہت سی الگ ہوتی پروڈکٹس برقرار نہ رکھیں اور ہر تبدیلی دس گنا لاگت لے۔
شور مچانے والے ہمسایوں کا کوئی دفاع نہیں۔ فی ٹیننٹ کوٹوں یا انصاف کے بغیر مشترک پول چلانا، تو اچھلنے والا پہلا ٹیننٹ سب کو گرا دے۔
آف بورڈنگ بعد کا خیال۔ ڈیٹا کی برآمد اور ثابت شدہ حذف کے بغیر بنانا، پھر گاہک کی باہر نکلنے کی شق یا رازداری کے قانون کی درخواست میں ناکام ہونا کیونکہ مشترک اسکیما نکالنا تکلیف دہ بناتا ہے۔
فی ٹیننٹ اندھے اڑنا۔ ٹیننٹ کے پہلو کے بغیر لاگز، میٹرکس، اور لاگت، تو آپ نہیں بتا سکتے کہ واقعہ کس کا ہے یا کون سا ٹیننٹ غیر منافع بخش ہے۔

پختگی کا ماڈل

سطح 1، آغاز: ملٹی ٹیننسی فی البدیہہ اور ردعملی ہے۔ ٹیننٹ کی علیحدگی پشت پناہی کے بغیر ہاتھ سے لکھے فلٹرز پر ٹکی ہے، ماڈل سب کے لیے ایک ہی ہے، کوئی کوٹے نہیں، آن بورڈنگ دستی ہے، اور لاگز اور لاگت کا کوئی ٹیننٹ کا پہلو نہیں۔ ٹیم شور مچانے والے ہمسائے اور قریب کی لیک کے بارے میں واقعات سے سیکھتی ہے۔
سطح 2، ترقی: بنیادی عمل ظاہر ہوتے ہیں مگر ٹیموں میں غیر مستقل ہیں۔ ٹیننسی ماڈل چنا گیا ہے اور ٹیننٹ کا سیاق بنیادی درخواست کے راستے سے گزرتا ہے، ڈیٹا بیس کی سطح یا ڈیٹا تک رسائی کی پشت پناہی بنیادی ٹیبلز پر دائرہ نافذ کرتی ہے، اور بنیادی فی ٹیننٹ کوٹے موجود ہیں۔ آن بورڈنگ جزوی طور پر خودکار ہے اور لاگز ٹیننٹ کا شناخت کنندہ رکھتے ہیں، مگر پس منظر کے راستے، برآمد، اور لاگت کی نسبت سروس سے سروس مختلف ہیں اور کہیں لکھے نہیں۔
سطح 3، معیار بندی: ٹیننسی کا طریقہ دستاویزی اور ادارے بھر میں نافذ ہے۔ درجہ دار ٹیننسی قیمتوں سے ملتی ہے، چھوٹے ٹیننٹس کے لیے مشترک پول اور انٹرپرائز اور ضابطے کے پابند کے لیے الگ تھلگ تعیناتیوں کے ساتھ، ٹیننٹ کی حد گہرائی میں نافذ اور جان بوجھ کر ٹیسٹ شدہ ہے، کوٹے اور منصفانہ شیڈولنگ شور مچانے والے ہمسایوں کو قابو کرتے ہیں، برآمد اور ثابت شدہ حذف سمیت ٹیننٹ کا زندگی کا چکر خودکار ہے، اور مشاہدہ پذیری اور لاگت فی ٹیننٹ کاٹی جاتی ہے۔ ہر ٹیم اپنے معیار کی بجائے وہی ٹیننسی کا معیار اپناتی ہے۔
سطح 4، انتظام: ٹیننسی کی جائیداد بنیادی خطوط کے مقابل ناپی اور کنٹرول کی جاتی ہے۔ فی ٹیننٹ علیحدگی، انصاف، لیٹنسی، اور لاگت متفقہ اہداف کے ساتھ میٹرکس کے طور پر ٹریک ہوتی ہے: ٹیننٹوں کے پار ٹیسٹ کی کوریج، کوٹے کی خلاف ورزی اور شور مچانے والے ہمسایوں کے واقعات کی شرحیں، آن بورڈنگ اور آف بورڈنگ کا وقت، اور فی ٹیننٹ منافع بنیادی خطوط کے مقابل رپورٹ ہوتے ہیں، اور ٹیننٹ کو درجوں کے درمیان ترقی دینے یا غیر منافع بخش کی قیمت دوبارہ لگانے کے فیصلے حکایت کی بجائے اس شہادت پر ہوتے ہیں۔ مقام اور درجہ بندی کی مطابقت کی مسلسل نگرانی ہوتی ہے، اور معیار سے بھٹکاؤ دستاویزی ردعمل چلاتا ہے۔
سطح 5، ہم آہنگی: ٹیننسی پورے ادارے میں مسلسل بہتر اور مربوط ہے۔ ٹیننٹوں کے پار حدیں معمول کی ریڈ ٹیم کی مشقوں سے آزمائی جاتی ہیں، ٹیننٹ بغیر بندش کے درجوں کے درمیان منتقل ہوتے ہیں جب وہ بڑھتے ہیں یا ان کی تعمیل کی ضروریات بدلتی ہیں، فی ٹیننٹ منافع قیمتوں اور صلاحیت کی منصوبہ بندی کو کھلاتا ہے، اور مقام اور درجہ بندی کے اصول ریویو کی بجائے پالیسی سے نافذ ہیں۔ گاہکوں کی ترکیب اور ضابطے کی تصویر بدلنے کے ساتھ ماڈل ڈھلتا ہے، اور سیکھے گئے اسباق پروڈکٹ، سلامتی، اور مالیات کو ایک چکر کے طور پر کھلاتے ہیں۔

بحث کے لیے خیالات

آج آپ کا ہر گاہک کا درجہ علیحدگی بمقابلہ کارکردگی کے طیف پر کہاں بیٹھتا ہے، اور کیا کوئی درجہ ان ضمانتوں یا اس منافع کے لیے غلط ماڈل میں ہے جو آپ نے بیچا یا آپ کو چاہیے؟
اگر آپ کو آڈیٹر کے سامنے ثابت کرنا ہو کہ ٹیننٹ A ٹیننٹ B کے ڈیٹا تک نہیں پہنچ سکتا تو آپ ابھی کون سی شہادت پیش کر سکتے ہیں، اور اس کا کتنا حصہ خودکار بمقابلہ دعویٰ ہے؟
آپ کے کون سے غیر ہم وقت راستے (کام، کیش، webhooks، برآمدات، تلاش کے انڈیکس) ٹیننٹ کا سیاق دوبارہ قائم کرتے ہیں، اور کون سے محض وراثت میں لیتے ہیں یا کال کرنے والے پر بھروسہ کرتے ہیں؟
جب ٹیننٹ منصفانہ بانٹ سے بڑھ جائے تو کیا آپ کے پاس bridge یا مخصوص تعیناتی میں معاون، قیمت لگا ہوا ترقی کا راستہ ہے، یا جواب ڈیفالٹ سے واقعہ ہے؟
کیا آپ انفراسٹرکچر کی لاگت کو انفرادی ٹیننٹس کو اتنی اچھی طرح منسوب کر سکتے ہیں کہ اپنے سب سے کم منافع بخش گاہک کا نام لیں، اور کیا اس سے آپ کی قیمتیں بدلیں گی؟
سرکاری یا ضابطے کے پابند ٹیننٹ کے لیے، کیا آپ ڈیٹا کے مقام اور درجہ بندی سے چلنے والی علیحدگی پالیسی سے نافذ کر سکتے ہیں، اور تصدیق شدہ برآمد اور ثابت شدہ حذف کے ساتھ آف بورڈ کر سکتے ہیں؟

اہم نکات

ملٹی ٹیننسی، ایک انسٹینس جو بہت سے ٹیننٹس کی خدمت کرے، SaaS کا معاشی انجن ہے: یہ آپ کا منافع چلاتی ہے، اور ٹیننٹوں کے پار علیحدگی کو آپ کے فن تعمیر کے مرکز میں رکھتی ہے۔
علیحدگی بمقابلہ کارکردگی کو طیف سمجھیں اور اسے درجہ بند کریں: چھوٹے ٹیننٹس کو موثر مشترک پول میں پیک کریں، بڑے اور ضابطے کے پابند ٹیننٹس کو bridge یا silo تعیناتیوں میں الگ کریں جن کی وہ ادائیگی کریں گے۔
ٹیننٹ کی حد کو ہاتھ سے لکھے فلٹر پر کبھی نہ ٹکائیں؛ اسے row-level سلامتی یا ڈیٹا تک رسائی کی تہہ سے گہرائی میں نافذ کریں، اور حد کو جان بوجھ کر ٹیسٹ کریں۔
ٹیننٹ کا سیاق ہر درخواست، کام، کیش، اور لاگ سے گزاریں، اور ان غیر ہم وقت راستوں کا دفاع کریں جہاں لیک چھپتے ہیں۔
فی ٹیننٹ کوٹوں، شرح کی حدوں، اور منصفانہ شیڈولنگ سے شور مچانے والے ہمسایوں کو قابو کریں، اور پول سے بڑھنے والے ٹیننٹس کو انہیں بگاڑنے دینے کی بجائے ترقی دیں۔
پروڈکٹ کو فی ٹیننٹ ترتیب سے موڑیں، فی ٹیننٹ کوڈ سے نہیں، اور ٹیننٹ کے زندگی کے چکر اور فی ٹیننٹ مشاہدہ پذیری اور لاگت کی نسبت کو اولین درجے کا بنائیں۔

حوالہ جات اور مزید مطالعہ

Tom Kwok, Thao Nguyen, and Linh Lam, A Software as a Service with Multi-tenancy Support for an Electronic Contract Management Application (IEEE International Conference on Services Computing)
Frederick Chong and Gianpaolo Carraro, Architecture Strategies for Catching the Long Tail (Microsoft)
Amazon Web Services, SaaS Lens, AWS Well-Architected Framework and SaaS Tenant Isolation Strategies
Microsoft, Multitenant SaaS architecture and patterns (Azure Architecture Centre)
Google Cloud, Architecture for Multi-tenant SaaS Applications
Cor-Paul Bezemer and Andy Zaidman, Multi-Tenant SaaS Applications: Maintenance Dream or Nightmare? (Proceedings of the Joint ERCIM Workshop on Software Evolution)
The Open Web Application Security Project, OWASP Application Security Verification Standard (access-control and multi-tenancy requirements)
Martin Kleppmann, Designing Data-Intensive Applications (partitioning, sharding, and data isolation)