मल्टी-टेनेंट आर्किटेक्चर: डायलर को इसकी आवश्यकता क्यों है?

यदि आप बीपीओ, रीसेलर व्यवसाय या कोई भी ऐसा ऑपरेशन चलाते हैं जो एक ही डायलर प्लेटफॉर्म पर कई ग्राहकों को सेवा प्रदान करता है, तो मल्टी-टेनेन्सी कोई अतिरिक्त सुविधा नहीं है। यह वह आधार है जिस पर बाकी सब कुछ टिका हुआ है।

मल्टी-टेनेन्सी का असल मतलब क्या है?

मल्टी-टेनेन्सी का अर्थ है कि कई स्वतंत्र क्लाइंट (किरायेदार) एक ही सॉफ़्टवेयर इन्फ्रास्ट्रक्चर को साझा करते हैं, जबकि उनका डेटा, कॉन्फ़िगरेशन और अनुपालन नियम पूरी तरह से अलग-अलग होते हैं। प्रत्येक किरायेदार ऐसे काम करता है जैसे उसके पास अपना समर्पित सिस्टम हो - लेकिन अंतर्निहित प्लेटफ़ॉर्म साझा होता है।

मुख्य शब्द है isolationपृथक्करण नहीं। फ़िल्टरिंग नहीं। अलगाव।

एकांत क्यों महत्वपूर्ण है

डेटा सुरक्षा। क्लाइंट A के संपर्क, कॉल रिकॉर्डिंग, एजेंट डेटा और कैंपेन के परिणाम क्लाइंट B के लिए अदृश्य होने चाहिए। सिर्फ़ छिपे हुए ही नहीं, बल्कि सिद्ध रूप से दुर्गम होने चाहिए। यदि कोई डेवलपर क्वेरी में गलती करता है, तब भी डेटाबेस को क्रॉस-टेनेंट डेटा एक्सेस को रोकना चाहिए।

अनुपालन स्वतंत्रता। क्लाइंट A संयुक्त अरब अमीरात (UAE) के TDRA नियमों के अंतर्गत काम कर सकता है। क्लाइंट B सऊदी अरब (KSA) के CITC नियमों के अंतर्गत और क्लाइंट C अमेरिका (TCPA) नियमों के अंतर्गत काम कर सकता है। प्रत्येक किरायेदार को अपने स्वयं के अनुपालन नियम, DNC सूचियाँ, कॉलिंग घंटे और सहमति ट्रैकिंग की आवश्यकता होती है। एक किरायेदार द्वारा अनुपालन उल्लंघन दूसरे को प्रभावित नहीं कर सकता।

रिकॉर्डिंग आइसोलेशन। कॉल रिकॉर्डिंग किसी भी संपर्क केंद्र का सबसे संवेदनशील डेटा होता है। प्रत्येक उपयोगकर्ता की रिकॉर्डिंग को उपयोगकर्ता-विशिष्ट पहुँच नियंत्रणों के साथ पृथक संग्रहण पथों में संग्रहीत किया जाना चाहिए। क्लाइंट A की रिकॉर्डिंग के लिए हस्ताक्षरित URL क्लाइंट B के लिए कभी भी काम नहीं करना चाहिए।

बिलिंग अलगाव। प्रत्येक किरायेदार के अपने एजेंटों की संख्या, उपयोग के मापदंड और बिलिंग चक्र होते हैं। प्रत्येक किरायेदार के लिए बिलिंग डेटा सटीक होना चाहिए और उसमें किसी प्रकार की मिलावट नहीं होनी चाहिए।

गलत तरीका: एप्लिकेशन-स्तरीय फ़िल्टरिंग

कई डायलर एक सरल तरीके से "मल्टी-टेनेन्सी" लागू करते हैं। जहां tenant_id = ? उन्होंने अपने एप्लिकेशन कोड में फ़िल्टर जोड़ा है। हर क्वेरी में यह फ़िल्टर जुड़ जाता है। यह तब तक काम करता है... जब तक कोई इसे भूल न जाए।

समस्याएं:

• एक फ़िल्टर छूट जाने से सभी किरायेदारों के बीच डेटा लीक हो सकता है
• जॉइन वाले जटिल प्रश्नों में गलती होने की संभावना अधिक होती है।
• एग्रीगेशन क्वेरी (रिपोर्ट, डैशबोर्ड) विशेष रूप से जोखिम भरी होती हैं।
• एप्लिकेशन में गलती होने पर कोई सुरक्षा कवच नहीं होता।

एप्लिकेशन-स्तर का फ़िल्टरिंग अलगाव नहीं है। यह एक ऐसा फ़िल्टर है जो हर डेवलपर, हर क्वेरी और हर कोड पाथ में हर बार 100% सही होने पर निर्भर करता है। यह पर्याप्त नहीं है।

सही तरीका: डेटाबेस-स्तरीय अलगाव

DialerBee सुरक्षा की एक अतिरिक्त परत के रूप में PostgreSQL Row Level Security (RLS) का उपयोग करता है। यह इस प्रकार काम करता है:

1. किरायेदार के स्वामित्व वाली प्रत्येक मेज पर एक tenant_id column
2. RLS नीतियां प्रत्येक टेनेंट टेबल पर सक्षम और लागू हैं।
3. प्रत्येक डेटाबेस लेनदेन की शुरुआत में, हम सेट करते हैं SET LOCAL app.current_tenant_id = :tid
4. डेटाबेस स्वयं ही प्रत्येक क्वेरी — SELECT, INSERT, UPDATE, DELETE — को फ़िल्टर करता है ताकि केवल वर्तमान टेनेंट से मेल खाने वाली पंक्तियाँ ही वापस मिलें।
5. एप्लिकेशन उपयोगकर्ता के पास BYPASSRLS की अनुमति नहीं है — यहां तक कि रॉ SQL भी फ़िल्टर से बच नहीं सकता।

इसका मतलब यह है कि यदि एप्लिकेशन कोड में कोई त्रुटि हो — जैसे कि WHERE क्लॉज़ का न होना, गलत JOIN, या बिना ग्रुपिंग के एग्रीगेशन — तो भी डेटाबेस क्रॉस-टेनेंट डेटा एक्सेस को रोकता है। एप्लिकेशन का फ़िल्टर प्राथमिक सुरक्षा कवच है। RLS एक अतिरिक्त सुरक्षा कवच है।

परीक्षण अलगाव

केवल आइसोलेशन का दावा करना ही काफी नहीं है। आपको इसे साबित करना होगा। डायलरबी हर एपीआई एंडपॉइंट पर एडवर्सरियल टेनेंट आइसोलेशन टेस्ट चलाता है:

1. किरायेदार A एक संसाधन (संपर्क, अभियान, रिकॉर्डिंग आदि) बनाता है।
2. किरायेदार B उस संसाधन पर GET, PATCH, DELETE कमांड चलाने का प्रयास करता है।
3. प्रत्येक प्रयास में 404 (नहीं मिला) त्रुटि आनी चाहिए, कभी भी 403 (निषिद्ध) त्रुटि नहीं आनी चाहिए।

403 की जगह 404 क्यों? क्योंकि 403 ("आपके पास अनुमति नहीं है") संसाधन के अस्तित्व की पुष्टि करता है। 404 ("नहीं मिला") कुछ भी प्रकट नहीं करता। किरायेदार B को तो यह भी नहीं पता होना चाहिए कि संसाधन मौजूद है।

ये टेस्ट हर कोड परिवर्तन पर CI में चलते हैं। यदि कोई भी टेस्ट विफल हो जाता है, तो कोड मर्ज नहीं होता है।

साझेदारों को क्या मांग करनी चाहिए

यदि आप व्हाइट-लेबल या पुनर्विक्रेता उपयोग के लिए किसी डायलर का मूल्यांकन कर रहे हैं, तो ये प्रश्न पूछें:

• क्या डेटाबेस स्तर पर टेनेंट आइसोलेशन लागू किया जाता है, या केवल एप्लिकेशन कोड में?
• क्या आप मुझे एडवर्सरियल आइसोलेशन टेस्ट सूट दिखा सकते हैं?
• यदि किसी क्वेरी में गलती से टेनेंट फ़िल्टर छूट जाए तो क्या होगा?
• क्या कॉल रिकॉर्डिंग किरायेदार-पृथक पथों में संग्रहीत की जाती हैं?
• क्या एक किरायेदार द्वारा नियमों का उल्लंघन करने से दूसरे किरायेदार पर असर पड़ सकता है?
• यदि मैं पार्टनर पोर्टल के माध्यम से एक टेनेंट बनाता हूं, तो क्या वह तुरंत अन्य सभी टेनेंट से अलग हो जाता है?

यदि इनमें से किसी भी प्रश्न का उत्तर अस्पष्ट है, तो आगे खोजते रहें। गलत तरीके से की गई मल्टी-टेनेन्सी, बिल्कुल भी मल्टी-टेनेन्सी न होने से भी बदतर है — क्योंकि इससे आपको सुरक्षा का झूठा एहसास होता है।