मल्टी-टेनेंट Laravel: प्रोडक्शन में एक डेटाबेस या कई

ग्राहकों को अलग रखने के दो तरीके

मल्टी-टेनेंट ऐप्लिकेशन में हर ग्राहक (टेनेंट) एक ही कोडबेस साझा करता है, लेकिन उसे सिर्फ़ अपना डेटा दिखना चाहिए। Laravel में ऐसा करने के दो मुख्य तरीके हैं।

सिंगल-डेटाबेस मॉडल में ग्राहक डेटा वाली हर टेबल में tenant_id कॉलम होता है और हर क्वेरी मौजूदा टेनेंट तक सीमित रहती है। मल्टी-डेटाबेस मॉडल में हर टेनेंट का अपना डेटाबेस (या स्कीमा) होता है और ऐप्लिकेशन सक्रिय टेनेंट पता चलते ही कनेक्शन बदल देता है। दोनों प्रोडक्शन में अच्छे चलते हैं; बस अलग तरह से फ़ेल होते हैं।

एक डेटाबेस: ताकत और जोखिम

एक डेटाबेस चलाना आसान है: एक सेट माइग्रेशन, एक बैकअप, एक कनेक्शन पूल और सभी ग्राहकों पर आसान रिपोर्टिंग। यह सस्ता भी है: हज़ार छोटे टेनेंट का खर्च एक जैसा ही है।

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

कई डेटाबेस: ताकत और जोखिम

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

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

Laravel में सिंगल-डेटाबेस टेनेंसी सही करना

• टेनेंट को एक बार और जल्दी पहचानें — मिडलवेयर में, डोमेन, सबडोमेन या लॉग इन यूज़र से — और उसे एक ही जगह रखें।
• एक साझा trait से global scope लगाएँ और मॉडल बनते समय tenant_id अपने आप सेट करें।
• कंपोज़िट इंडेक्स tenant_id से शुरू करें और unique constraint में tenant_id शामिल करें (जैसे tenant_id + email)।
• हर क्यू जॉब में टेनेंट ID भेजें और जॉब चलने से पहले उसे वापस सेट करें।
• कैश की और फ़ाइल स्टोरेज पाथ के आगे टेनेंट जोड़ें।
• ऐसे टेस्ट लिखें जो दो टेनेंट बनाएँ और पक्का करें कि एक कभी दूसरे के रिकॉर्ड न पढ़ सके।

trait BelongsToTenant
{
    protected static function bootBelongsToTenant(): void
    {
        static::addGlobalScope('tenant', fn ($query) => $query->where('tenant_id', tenant()->id));

        static::creating(fn ($model) => $model->tenant_id ??= tenant()->id);
    }
}

मल्टी-डेटाबेस टेनेंसी सही करना

टेनेंट, डोमेन, प्लान और बिलिंग के लिए एक केंद्रीय डेटाबेस रखें, और हर टेनेंट के डेटा के लिए अलग डेटाबेस। मिडलवेयर और क्यू जॉब में डिफ़ॉल्ट कनेक्शन बदलें और बाद में रीसेट करें, ताकि लंबे समय तक चलने वाला वर्कर कभी गलत टेनेंट पर न रहे।

टेनेंट माइग्रेशन ऐसे कमांड से चलाएँ जो सभी टेनेंट पर चले, प्रगति लॉग करे और फ़ेल होने के बाद वहीं से शुरू हो सके। डेटाबेस सर्वर की कनेक्शन सीमा पर नज़र रखें और बहुत वर्कर हों तो कनेक्शन पूलर इस्तेमाल करें। stancl/tenancy और spatie/laravel-multitenancy जैसे पैकेज इसका बड़ा हिस्सा संभालते हैं और दोनों मॉडल सपोर्ट करते हैं।

हाइब्रिड मॉडल

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

कैसे तय करें

• बहुत छोटे ग्राहक और छोटी टीम: एक डेटाबेस।
• अलगाव, ग्राहक-वार रीस्टोर या तय डेटा लोकेशन माँगने वाले कॉन्ट्रैक्ट: कई डेटाबेस, या हाइब्रिड।
• भारी वर्कलोड वाले कुछ बहुत बड़े ग्राहक: हाइब्रिड, उनके लिए अलग डेटाबेस के साथ।
• पक्का नहीं: हर जगह tenant_id और मज़बूत अलगाव टेस्ट के साथ एक डेटाबेस — इससे सारे विकल्प खुले रहते हैं।