आप जो क्षेत्र चुनते हैं, उससे तय होता है कि Bird आपके संगठन का डेटा कहाँ संग्रहीत और प्रोसेस करता है। इससे यह भी प्रभावित होता है कि सीमा-पार गोपनीयता के कौन-से नियम लागू होते हैं।
मेरा डेटा कहाँ रहता है?
एक ही क्षेत्र में, जिसे संगठन बनाते समय चुना जाता है।
हर Bird संगठन को साइनअप के समय एक क्षेत्र सौंपा जाता है। us1 संयुक्त राज्य अमेरिका है और eu1 यूरोपीय संघ है, और क्षेत्र दस्तावेज़ बताता है कि यह असाइनमेंट किन चीज़ों पर लागू होता है:
Every organization is assigned a region at signup. The region is detected from your location, can be changed before you confirm, and is immutable in v1. The workspace, API keys, messages, recipient data, and event logs remain in that region. They are never replicated across regions.
यहाँ मुख्य वाक्यांश "never replicated" है। अगर कोई रेज़िडेंसी प्रतिबद्धता रिडंडेंसी या एनालिटिक्स के लिए कहीं और प्रति रखने की अनुमति दे, तो वह रेज़िडेंसी प्रतिबद्धता नहीं होगी। यहाँ डेटा प्लेन हर क्षेत्र के लिए सचमुच अलग है, और इसी कारण यह चुनाव बदला नहीं जा सकता। किसी संगठन को एक क्षेत्र से दूसरे में ले जाना कोई सेटिंग नहीं, बल्कि माइग्रेशन है, जो मौजूदा API संस्करण में उपलब्ध नहीं है।
इसे कैसे लागू किया जाता है?
क्रेडेंशियल और रूटिंग दोनों में, ताकि कोई गलती हो तो अनुरोध साफ़ तौर पर विफल हो।
डेटा प्लेन के लिए कोई एक वैश्विक एंडपॉइंट नहीं है। हर क्षेत्र का अपना होस्ट है, और API कुंजी के प्रीफ़िक्स में उसका क्षेत्र लिखा होता है: bk_eu1_ कुंजी eu1 की होती है। SDK और CLI प्रीफ़िक्स पढ़कर बिना किसी कॉन्फ़िगरेशन के सही होस्ट चुन लेते हैं।
जब कोई अनुरोध गलत जगह पहुँचता है, तो यह होता है:
A request that reaches the wrong region is rejected with
421 Misdirected Requestinstead of being forwarded. The error message names the correct host
अनुरोध को आगे भेजने के बजाय अस्वीकार करना वह डिज़ाइन निर्णय है, जिससे रेज़िडेंसी की जाँच की जा सकती है। अगर कोई प्लेटफ़ॉर्म गलत जगह पहुँचे अनुरोध को चुपचाप प्रॉक्सी कर दे, तो यह सुविधाजनक होगा, लेकिन तब व्यक्तिगत डेटा वाला अनुरोध किसी के ध्यान में आने से पहले ही सीमा पार कर चुका होगा। यहाँ ऐसा नहीं हो सकता: अनुरोध विफल होता है, और त्रुटि में सही होस्ट का नाम होता है।
हर प्रतिक्रिया में एक X-Bird-Region हेडर भी होता है, जो बताता है कि किस क्षेत्र ने उसे सर्व किया। इससे आप कॉन्फ़िगरेशन पर भरोसा करने के बजाय पुष्टि कर सकते हैं कि कॉल असल में कहाँ पहुँची।
कौन-सी चीज़ें किसी क्षेत्र से बंधी नहीं हैं?
ऑथेंटिकेशन और खाता प्रबंधन, और दस्तावेज़ इसे स्पष्ट रूप से बताता है:
Only authentication and account administration (
/v1/auth,/v1/admin) operate on globally replicated data, which is why they are served from the non-region hostplatform.bird.com.
इस बात को नज़रअंदाज़ करने के बजाय समझना ज़रूरी है। साइन इन करने और अकाउंट प्रबंधित करने में ऐसा पहचान डेटा इस्तेमाल होता है जिसे कहीं से भी काम करना होता है। इसलिए ये दोनों हिस्से डिज़ाइन के तहत ग्लोबल हैं, जबकि मैसेज और प्राप्तकर्ताओं से जुड़ा सब कुछ ग्लोबल नहीं है। अगर आप अपने डेटा फ़्लो का दस्तावेज़ बना रहे हैं, तो सीमा इसी विभाजन पर खींचें।
क्या रेज़िडेंसी तय करती है कि मेरे मैसेज कहाँ जाते हैं?
नहीं, और दोनों को एक मान लेने से दोनों ही दिशाओं में गलत निष्कर्ष निकलता है।
रेज़िडेंसी का मतलब है कि आपका डेटा कहाँ स्टोर और प्रोसेस होता है। डिलीवरी इस पर निर्भर करती है कि आपके प्राप्तकर्ता कहाँ हैं, और इसे कवरेज, स्थानीय नियम और प्रतिबंध तय करते हैं। eu1 संगठन उन सभी जगहों के प्राप्तकर्ताओं को भेज सकता है जहाँ Bird डिलीवर करता है, और us1 संगठन यूरोपीय प्राप्तकर्ताओं को भेज सकता है। डिलीवरी से जुड़ी जानकारी समर्थित देश और प्रतिबंध में है।
रेज़िडेंसी यह ज़रूर तय करती है कि भेजने के बाद उस मैसेज का रिकॉर्ड कहाँ रहता है: खुद मैसेज, प्राप्तकर्ता डेटा और इवेंट लॉग। डेटा सुरक्षा से जुड़ा सवाल आमतौर पर इसी रिकॉर्ड के बारे में होता है।
मुझे शुरुआत में क्या तय करना चाहिए?
रीजन, क्योंकि इसमें यही एक हिस्सा है जिसे आप बाद में बदल नहीं सकते।
पुष्टि के बाद असाइनमेंट बदला नहीं जा सकता, इसलिए रीजन चुनना उसी प्रक्रिया का हिस्सा होना चाहिए जिससे आप अपना प्रोडक्शन संगठन बनाते हैं, बाकी एक बार तय होने वाली चीज़ों के साथ। गलत रीजन में बना टेस्ट संगठन छोटी असुविधा है; प्रोडक्शन संगठन के लिए माइग्रेशन करना पड़ता है।
इसी समय दो संबंधित बातें भी तय करें, क्योंकि ज़्यादातर समीक्षाओं में ये साथ आती हैं: संबंध को नियंत्रित करने वाला डेटा प्रोसेसिंग समझौता, और यह कि प्रदाता अपनी सब-प्रोसेसर सूची कहाँ प्रकाशित करता है। किसी दूसरे क्षेत्राधिकार में मौजूद सब-प्रोसेसर डेटा ट्रांसफ़र का सवाल है, जिसका जवाब अकेले रेज़िडेंसी से नहीं मिलता।
संक्षेप में
रेज़िडेंसी संगठन की विशेषता है, किसी अनुरोध की नहीं।
क्षेत्र साइनअप के समय तय होता है। पुष्टि करने से पहले आप इसे बदल सकते हैं, और उसके बाद API के मौजूदा संस्करण में इसे बदला नहीं जा सकता।
कोई भी डेटा क्षेत्रों के बीच कॉपी नहीं किया जाता।
वर्कस्पेस, कुंजियाँ, संदेश, प्राप्तकर्ता डेटा और इवेंट लॉग एक ही क्षेत्र में रहते हैं। इसी कारण रेज़िडेंसी की प्रतिबद्धता वास्तव में सार्थक होती है।
API कुंजी में उसका क्षेत्र शामिल होता है, और गलत होस्ट पर भेजा गया अनुरोध अस्वीकार होता है।
गलत क्षेत्र में पहुँचने वाले अनुरोध को चुपचाप आगे भेजने के बजाय
421 Misdirected Requestलौटाया जाता है, जिसमें सही होस्ट का नाम होता है।दो सेवाएँ जानबूझकर ग्लोबल रखी गई हैं।
ऑथेंटिकेशन और अकाउंट प्रबंधन कॉपी किए गए डेटा पर चलते हैं। इसलिए वे ऐसे होस्ट पर जवाब देते हैं जो किसी क्षेत्र से बँधा नहीं है।