हर क्लाइंट के लिए एक सिस्टम, या हर क्लाइंट के लिए एक प्लेटफ़ॉर्म। आर्किटेक्चर तय करता है कि आप कैसे स्केल करेंगे।

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

DialerBee डिज़ाइन से ही मल्टी-टेनेंट है और डेटा लेयर पर आइसोलेशन लागू करता है। हर रिकॉर्ड में टेनेंट की पहचान होती है, और एक्सेस इस तरह सीमित है कि क्वेरी सिर्फ अनुरोध करने वाले टेनेंट की पंक्तियां ही लौटा सकती हैं — यह तरीका आमतौर पर PostgreSQL रो-लेवल सिक्योरिटी जैसे डेटाबेस मैकेनिज़्म से लागू किया जाता है। इसका मतलब है कि क्लाइंट के बीच अलगाव खुद डेटा प्लेटफ़ॉर्म लागू करता है, इसे सिर्फ ऐप्लिकेशन कोड पर नहीं छोड़ा जाता।

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

कई क्लाइंट के लिए आउटबाउंड कॉलिंग संभालने वाले संगठनों के लिए मल्टी-टेनेंट आर्किटेक्चर सही डिफ़ॉल्ट है, लेकिन सिंगल-टेनेंट पुराना नहीं पड़ा है। कुछ स्थितियों में समर्पित इंस्टेंस बेहतर विकल्प बना रहता है।

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

जो संगठन सिर्फ एक क्लाइंट को सेवा देते हैं — या खुद ही अकेले अंतिम यूज़र हैं — उन्हें मल्टी-टेनेंसी से कम फ़ायदा होता है, क्योंकि अलग करने के लिए कोई दूसरा टेनेंट है ही नहीं। ऐसे मामलों में एक वातावरण की ऑपरेशनल सरलता साझा प्लेटफ़ॉर्म के फ़ायदों पर पूरी तरह भारी पड़ सकती है।

बाकी सबके लिए — वे BPO, टेलीकॉम रीसेलर और एजेंसियां जो नियमित रूप से क्लाइंट जोड़ती हैं और जिन्हें प्रति-क्लाइंट बोझ के बिना प्रति-क्लाइंट अलगाव चाहिए — एक अच्छी तरह बना मल्टी-टेनेंट प्लेटफ़ॉर्म एक ही सिस्टम की दक्षता के साथ अलग-अलग सिस्टम जैसा आइसोलेशन देता है। DialerBee इसी संतुलन के आसपास डिज़ाइन किया गया है, और यही कारण है कि हमारा BPO सॉल्यूशन और व्हाइट-लेबल डायलर प्लेटफ़ॉर्म मल्टी-टेनेंट नींव पर बने हैं।

DialerBee डिज़ाइन से ही मल्टी-टेनेंट है। आइसोलेशन PostgreSQL रो-लेवल सिक्योरिटी के साथ डेटाबेस लेयर पर लागू होता है, इसलिए हर क्वेरी अनुरोध करने वाले टेनेंट तक सीमित रहती है और टेनेंट के बीच एक्सेस को ऐप्लिकेशन लॉजिक नहीं, डेटाबेस इंजन रोकता है। हर टेनेंट के अपने अनुपालन नियम, स्वतंत्र रिटेंशन और लीगल-होल्ड नियंत्रण वाली अपनी रिकॉर्डिंग, अपना उपयोग और बिलिंग एट्रिब्यूशन, और अपनी ब्रांडिंग होती है। नए टेनेंट एडमिन पोर्टल या पार्टनर API के ज़रिए मिनटों में बनते हैं। विस्तृत जानकारी यहां है: मल्टी-टेनेंट आर्किटेक्चर पेज.

एक्सेस ऐसी चीज़ है जिसे आप अनुमान लगाने के बजाय ग्रिड पर पढ़ सकते हैं: 11 परमिशन श्रेणियों और 41 परमिशन वाला प्रति-टेनेंट रोल मैट्रिक्स, कार्रवाई, यूज़र और उस IP एड्रेस को दर्ज करने वाला ऑडिट लॉग जहां से वह आई, स्टोर किए जाने पर हैश की गई और अपने टेनेंट तक सीमित API कीज़, और पार्टनर एडमिन जो सिर्फ अपने टेनेंट देखते हैं। यह कवर किया गया है सुरक्षा और एक्सेस पर। प्लेटफ़ॉर्म और पार्टनर एडमिनिस्ट्रेटर को इसके अलावा मिलता है ऑपरेशंस सेंटर जिसमें सेवाओं की सेहत, लाइव कॉल और शुरू से अंत तक कॉल ट्रेस हैं, जबकि टेनेंट एडमिनिस्ट्रेटर सिर्फ अपना टेनेंट देखते हैं।