मल्टीटेनेंसी और आइडेम्पोटेंसी

# gateway.env
# Owner pool — runs migrations and privileged maintenance
AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable
# Restricted role — activates RLS for normal request traffic
AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable

side-effect requested
   └─▶ compute resume-stable ledger key
         └─▶ barrier: key already committed?
               ├─ yes ─▶ skip (no double-send)
               └─ no  ─▶ perform effect ─▶ commit key

AiHummer है **मल्टीटेनेन्ट**: एक गेटवे एक ही डेटाबेस से कई कार्यक्षेत्रों की सेवा कर सकता है जबकि उनके डेटा को अलग रखता है। इसे सुरक्षित बनाने के लिए दो तंत्र हैं — **पोस्टग्रेस रो-लेवल सुरक्षा (RLS)** पढ़ने/लिखने के अलगाव के लिए, और एक **आइडेम्पोटेंसी स्तर** ताकि पुनः प्रयास और मोड़ की रिकवरी कभी भी वास्तविक दुनिया के साइड-इफेक्ट को दोहराएँ। **स्तर:** पंक्ति-स्तर सुरक्षा बहु-किरायेदार अलगाव भुगतान द्वारा नियंत्रित है **उद्यम** स्तर — मुफ्त/सामुदायिक प्लेटफ़ॉर्म का हिस्सा नहीं; आइडेम्पोटेंसी लेयर कोर का हिस्सा है। ## रो-स्तरीय सुरक्षा के साथ किरायेदार पृथकता अलगाव केवल एप्लिकेशन कोड में ही नहीं, बल्कि डेटाबेस में भी लागू किया जाता है। AiHummer क्वेरियों को चलाता है **सीमित पोस्टग्रेज़ रोल** (`aihummer_app`) जिस पर RLS नीतियाँ लागू की गई हैं, ताकि डेटाबेस स्वयं उन पंक्तियों को अस्वीकार कर दे जो सक्रिय किरायेदार से संबंधित नहीं हैं। आरएलएस है **सहमति देना**. आप इसे सक्रिय करते हैं जब आप गेटवे को प्रतिबंधित भूमिका के लिए दूसरा कनेक्शन स्ट्रिंग देते हैं: ```ini # gateway.env # Owner pool — runs migrations and privileged maintenance AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable # Restricted role — activates RLS for normal request traffic AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable ``` > [!NOTE] > होस्ट-नेटिव इंस्टॉल के लिए इंस्टॉलर सेट करता है `AIHUMMER_DB_APP_URL` > स्वतः, इसलिए मानक तैनाती में RLS डिफ़ॉल्ट रूप से चालू होता है। यदि > चर अनुपस्थित है, गेटवे केवल मालिक पूल पर चलता है और RLS नहीं है > सक्रिय। ### प्रति-किरायेदार स्कोपिंग सीमित भूमिका के भीतर, प्रत्येक अनुरोध को उसके टेनेंट तक सीमित किया जाता है: गेटवे कनेक्शन पर वर्तमान टेनेंट संदर्भ सेट करता है ताकि RLS नीतियाँ सही वर्कस्पेस के खिलाफ हल हों। `WHERE tenant_id = …` फिल्टर हर जगह हाथ से नहीं बनाए जाते; नीति इसे केंद्रित रूप से लागू करती है, जिसका मतलब है कि कोई भी छूटा हुआ फिल्टर दूसरे किरायेदार की पंक्तियों को लीक नहीं कर सकता। ### सिस्टम / बाईपास मोड कुछ काम वैध रूप से क्रॉस-टेनेंट होते हैं — बैकग्राउंड वर्कर्स, शेड्यूलर्स और मेंटेनेंस जॉब्स जो पूरे इंस्टेंस में चलते हैं। ये चलते हैं एक **सिस्टम / बाईपास मोड** ताकि वे देख सकें कि उन्हें क्या देखने की ज़रूरत है। बायपास सिर्फ भरोसेमंद आंतरिक कर्मचारियों के लिए सुरक्षित है, अनुरोध-संभालने वाले पथों के लिए नहीं। > [!WARNING] > **स्थानांतरण हमेशा मालिक पूल पर चलते हैं**, कभी भी प्रतिबंधित भूमिका के तहत नहीं। > स्वामी कनेक्शन के पास स्कीमा बदलने और RLS लागू करने के अधिकार हैं > नीतियाँ; प्रतिबंधित भूमिका जानबूझकर ऐसा नहीं करती है। दोनों कनेक्शन को बनाए रखें > स्ट्रिंग्स अलग और प्रदान करें `aihummer_app` सिर्फ वही भूमिका जो इसे चाहिए। ## परिमित पार्श्व-प्रभाव एक टर्न वास्तविक दुनिया में साइड-इफेक्ट्स पैदा कर सकता है: मेल भेजना, किसी चैनल पर संदेश पोस्ट करना। यदि किसी टर्न को फिर से प्रयास किया जाता है — अस्थायी त्रुटि के कारण, या क्योंकि गेटवे टर्न के बीच में रीस्टार्ट हुआ और पुनर्प्राप्ति इसे दोहराती है — तो उन साइड-इफेक्ट्स को **नहीं** दो बार होना। AiHummer दो सहयोगी टुकड़ों के साथ यह सुनिश्चित करता है। ### एक रिज्यूमे-स्थिर लेजर कुंजी प्रत्येक दुष्प्रभाव को इसके खिलाफ दर्ज किया जाता है **रीस्यूमे-स्थिर खाता कुंजी**: एक कुंजी जो मोड़ से निर्धारणात्मक रूप से प्राप्त होती है, इसलिए उसी मोड़ को दोबारा चलाने पर *वही* कुंजी गणना होती है ना कि एक नई। खाते की पुस्तिका याद रखती है कि कौन सी चाबियाँ पहले ही क्रियान्वित की जा चुकी हैं। ### एक दुष्प्रभाव बाधा किसी प्रभाव से पहले जैसे **मेल** या **चैनल-सेंड** किया जाता है, यह से होकर गुजरता है **साइड-इफेक्ट बाधा** जो खाता विवरण जांचता है। अगर यह कुंजी पहले ही सक्रिय हो चुकी है, तो बाधा शॉर्ट-सर्किट हो जाती है और प्रभाव को छोड़ दिया जाता है; अगर नहीं, तो प्रभाव चलता है और कुंजी प्रतिबद्ध हो जाती है। ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` परिणाम यह है **सटीक-एक बार बाहरी व्यवहार भले ही आंतरिक रूप से डिलीवरी कम से कम एक बार हो**. पुनः प्रयास संरचना द्वारा सुरक्षित हैं, यही वह है जो टर्न रिकवरी की अनुमति देता है (देखें [भरोसेमंद डिलीवरी और रिकवरी](/hi/v1.0/architecture/delivery-outbox)) एक लंबित वार्तालाप को फिर से चलाएं बिना कि ग्राहक को वही ईमेल या वही उत्तर दो बार मिले। > [!TIP] > यही कारण है कि AiHummer गारंटीड डिलीवरी और स्वचालित टर्न रिकवरी की पेशकश कर सकता है > डुप्लिकेट संदेशों के सामान्य जोखिम के बिना — आइडेमपो्टेंसी आधार है > डिलीवरी की गारंटियाँ जिस पर आधारित हैं। ## अगला कहाँ - एक घुमाव को चलाने वाला रनटाइम: [गेटवे और टर्न इंजन](/hi/v1.0/architecture/gateway-turn-engine). - कैसे उत्तर ठीक एक बार लौटाए जाते हैं: [भरोसेमंद डिलीवरी और रिकवरी](/hi/v1.0/architecture/delivery-outbox).