ملٹی ٹیننٹ آرکیٹیکچر: ڈائلرز کو اس کی ضرورت کیوں ہے۔

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

کثیر کرایہ داری کا اصل مطلب کیا ہے۔

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

کلیدی لفظ ہے۔ isolation. جدائی نہیں۔ فلٹرنگ نہیں علیحدگی۔

تنہائی کیوں اہمیت رکھتی ہے۔

ڈیٹا کی حفاظت۔ کلائنٹ A کے رابطے، کال کی ریکارڈنگ، ایجنٹ کا ڈیٹا، اور مہم کے نتائج کلائنٹ B کے لیے پوشیدہ ہونے چاہئیں۔ نہ صرف پوشیدہ — ممکنہ طور پر ناقابل رسائی۔ اگر کوئی ڈویلپر کسی استفسار میں غلطی کرتا ہے، تو ڈیٹا بیس کو اب بھی کراس کرایہ دار ڈیٹا تک رسائی کو روکنا چاہیے۔

تعمیل کی آزادی۔ کلائنٹ A TDRA قوانین (UAE) کے تحت کام کر سکتا ہے۔ CITC (KSA) کے تحت کلائنٹ B۔ TCPA (US) کے تحت کلائنٹ C۔ ہر کرایہ دار کو اپنے تعمیل کے قوانین، DNC فہرستوں، کال کرنے کے اوقات اور رضامندی سے باخبر رہنے کی ضرورت ہوتی ہے۔ ایک کرایہ دار کی طرف سے تعمیل کی خلاف ورزی دوسرے کو متاثر نہیں کر سکتی۔

ریکارڈنگ تنہائی۔ کال ریکارڈنگ ایک رابطہ مرکز میں سب سے زیادہ حساس ڈیٹا ہوتا ہے۔ ہر کرایہ دار کی ریکارڈنگ کو کرایہ دار کے لیے مخصوص رسائی کے کنٹرول کے ساتھ الگ تھلگ اسٹوریج کے راستوں میں ذخیرہ کیا جانا چاہیے۔ کلائنٹ A کی ریکارڈنگ کے لیے دستخط شدہ URL کو کلائنٹ B کے لیے کبھی کام نہیں کرنا چاہیے۔

بلنگ تنہائی۔ ہر کرایہ دار کا اپنا ایجنٹ شمار، استعمال کی پیمائش اور بلنگ سائیکل ہوتا ہے۔ بلنگ ڈیٹا فی کرایہ دار درست ہونا چاہیے، بغیر کسی کراس آلودگی کے۔

غلط طریقہ: ایپلیکیشن لیول فلٹرنگ

بہت سے ڈائلر ایک سادہ کے ساتھ "ملٹی ٹینسی" کو نافذ کرتے ہیں۔ کہاں کرایہ دار_آئی ڈی = ؟ ان کے ایپلیکیشن کوڈ میں فلٹر کریں۔ ہر سوال اس فلٹر کو جوڑتا ہے۔ یہ اس وقت تک کام کرتا ہے جب تک کوئی بھول نہ جائے۔

مسائل:

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

ایپلیکیشن لیول فلٹرنگ تنہائی نہیں ہے۔ یہ ایک بہترین کوشش کرنے والا فلٹر ہے جو ہر ڈویلپر پر، ہر سوال پر، ہر کوڈ کے راستے پر 100% وقت پر منحصر ہوتا ہے۔ یہ کافی اچھا نہیں ہے۔

صحیح طریقہ: ڈیٹا بیس لیول آئسولیشن

DialerBee PostgreSQL Row Level Security (RLS) کو دفاعی گہرائی کی تہہ کے طور پر استعمال کرتا ہے۔ یہاں یہ ہے کہ یہ کیسے کام کرتا ہے:

1. ہر کرایہ دار کی ملکیت میں ایک میز ہے۔ tenant_id column
2. RLS پالیسیاں ہر کرایہ دار کی میز پر فعال اور مجبور ہیں۔
3. ہر ڈیٹا بیس ٹرانزیکشن کے آغاز پر، ہم سیٹ کرتے ہیں۔ مقامی ایپ سیٹ کریں۔current_tenant_id = :tid
4. ڈیٹا بیس خود ہر سوال کو فلٹر کرتا ہے — SELECT, INSERT, UPDATE, DELETE — صرف موجودہ کرایہ دار سے مماثل قطاریں واپس کرنے کے لیے
5. ایپلیکیشن کے صارف کے پاس BYPASSRLS کی اجازت نہیں ہے — یہاں تک کہ خام SQL بھی فلٹر سے بچ نہیں سکتا

اس کا مطلب ہے یہاں تک کہ اگر ایپلیکیشن کوڈ میں ایک بگ ہے — ایک گمشدہ WHERE شق، ایک خراب JOIN، بغیر گروپنگ کے ایک مجموعہ — ڈیٹا بیس کراس کرایہ دار ڈیٹا تک رسائی کو روکتا ہے۔ ایپلیکیشن کا فلٹر بنیادی دفاع ہے۔ RLS حفاظتی جال ہے۔

تنہائی کی جانچ

تنہائی کا دعوی کرنا کافی نہیں ہے۔ آپ کو اسے ثابت کرنے کی ضرورت ہے۔ DialerBee ہر API کے اختتامی نقطہ پر مخالف کرایہ دار الگ تھلگ ٹیسٹ چلاتا ہے:

1. کرایہ دار A ایک وسیلہ بناتا ہے (رابطہ، مہم، ریکارڈنگ، وغیرہ)
2. کرایہ دار B اس وسائل پر GET، PATCH، DELETE کی کوشش کرتا ہے۔
3. ہر کوشش کو 404 لوٹانا چاہیے (نہیں ملا)، کبھی نہیں 403 (ممنوع)

403 کے بجائے 404 کیوں؟ کیونکہ 403 ("آپ کو اجازت نہیں ہے") وسائل کے موجود ہونے کی تصدیق کرتا ہے۔ 404 ("نہیں ملا") کچھ بھی ظاہر نہیں کرتا ہے۔ کرایہ دار B کو یہ بھی معلوم نہیں ہونا چاہیے کہ وسائل موجود ہیں۔

یہ ٹیسٹ ہر کوڈ کی تبدیلی پر CI میں چلتے ہیں۔ اگر کوئی ٹیسٹ ناکام ہوجاتا ہے، تو کوڈ ضم نہیں ہوتا ہے۔

شراکت داروں کو کیا مطالبہ کرنا چاہئے۔

اگر آپ وائٹ لیبل یا ری سیلر کے استعمال کے لیے ڈائلر کا جائزہ لے رہے ہیں، تو یہ سوالات پوچھیں:

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

اگر ان میں سے کسی کا جواب مبہم ہے تو دیکھتے رہیں۔ ایک سے زیادہ کرایہ داری غلط کی گئی ہے اس سے کہیں زیادہ بدتر ہے کہ کوئی کثیر کرایہ داری نہیں ہے - کیونکہ آپ کو تحفظ کا غلط احساس ہے۔