टेनेंट, होस्ट और डेटा फ़िल्टर
ToRun, ABP Framework के मल्टी-टेनेंट मॉडल पर बना है। IsMultiTenant से चिह्नित पंक्ति में एक TenantId कॉलम होता है, जिस पर फ़्रेमवर्क अपने आप फ़िल्टर करता है; किसी एक टेनेंट के संदर्भ में चलाई गई क्वेरी कभी दूसरे टेनेंट की पंक्तियाँ नहीं देखती। होस्ट संदर्भ (TenantId == null) एक अलग हिस्सा देखता है: SubscriptionPlan, AiProvider और LegalDocument जैसे मानक कैटलॉग वहीं रहते हैं।
हम होस्ट को पूर्ण प्रतिभागी क्यों मानते हैं
ज़्यादातर SaaS उत्पाद होस्ट को "एडमिन टूल" के रूप में जोड़ते हैं। हम उसे एक सहोदर टेनेंट की तरह मॉडल करते हैं: होस्ट के अपने डैशबोर्ड, अपनी AI नीतियाँ और अपने बिलिंग संबंध होते हैं। इससे हम अपना प्रोडक्शन ट्रैफ़िक उन्हीं घटकों पर चला पाते हैं जिनका उपयोग हर ग्राहक करता है।
हर टेनेंट के लिए प्लान से जुड़ी सुविधाएँ
सब्सक्रिप्शन प्लान में FeatureLimit, Entitlement, Capability और Mode पंक्तियाँ होती हैं। जब कोई टेनेंट कोई प्लान सक्रिय करता है, तो उसे मिलने वाली सुविधाओं का समूह उसके प्लान और वैश्विक कैटलॉग का प्रतिच्छेदन होता है। नया मोड जोड़ने के लिए हर टेनेंट को छूने की ज़रूरत नहीं होती: अगर उसके प्लान में वह मोड शामिल है, तो उसे वह अपने आप मिल जाता है।
हर कॉल में BYOK इंजेक्शन
साझा इन्फ़्रास्ट्रक्चर होने पर भी BYOK क्रेडेंशियल उसी टेनेंट तक सीमित रहते हैं जिसके वे हैं। हर AI अनुरोध उसी डेटा फ़िल्टर के साथ टेनेंट संदर्भ में क्रेडेंशियल प्राप्त करता है; स्टोरेज परत पर टेनेंट के बीच कुंजियों का लीक होना संभव नहीं है।
हम जान-बूझकर क्या नहीं करते
हम टेनेंट को डेटाबेस या प्रोसेस स्तर पर अलग नहीं करते। हर टेनेंट के लिए अलग डेटाबेस को स्केल करने की लागत किसी मल्टी-टेनेंट SaaS उत्पाद की यूनिट इकोनॉमिक्स को बिगाड़ देती है। जब स्कीमा पहले दिन से इसके लिए डिज़ाइन किया गया हो, तो डेटा फ़िल्टर और प्रति-टेनेंट अलग कैश काफ़ी है।