डेटा रेज़िडेंसी क्या है, और मेरा मैसेज डेटा कहाँ स्टोर होता है?

आप जो रीजन चुनते हैं वह नियंत्रित करता है कि 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 Request instead 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 host platform.bird.com.

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

क्या रेज़िडेंसी तय करती है कि मेरे मैसेज कहाँ जाएँगे?

नहीं, और दोनों को एक मानना दोनों दिशाओं में गलत निष्कर्ष की ओर ले जाता है।

रेज़िडेंसी यह है कि आपका डेटा कहाँ स्टोर और प्रोसेस होता है। डिलीवरी यह है कि आपके प्राप्तकर्ता कहाँ हैं, जो कवरेज, स्थानीय नियमों और प्रतिबंधों द्वारा नियंत्रित होती है। eu1 ऑर्गनाइज़ेशन कहीं भी प्राप्तकर्ताओं को भेज सकता है जहाँ Bird डिलीवर करता है, और us1 ऑर्गनाइज़ेशन यूरोपीय प्राप्तकर्ताओं को भेज सकता है। समर्थित देश और प्रतिबंध डिलीवरी पक्ष को कवर करता है।

रेज़िडेंसी जो तय करती है वह यह है कि उस मैसेज का रिकॉर्ड बाद में कहाँ रहता है: मैसेज स्वयं, प्राप्तकर्ता डेटा, इवेंट लॉग। वह रिकॉर्ड आमतौर पर वही होता है जिसके बारे में डेटा सुरक्षा का सवाल वास्तव में होता है।

मुझे पहले से क्या तय करना चाहिए?

रीजन, क्योंकि यही इसका वह हिस्सा है जिसे आप दोबारा नहीं बदल सकते।

चूँकि असाइनमेंट कन्फ़र्म होने के बाद अपरिवर्तनीय है, रीजन चयन उसी प्रक्रिया में होना चाहिए जो आपका प्रोडक्शन ऑर्गनाइज़ेशन बनाती है, साथ ही बाकी सब कुछ जो एक बार तय किया जाता है। गलत रीजन में बना टेस्ट ऑर्गनाइज़ेशन एक छोटी परेशानी है; प्रोडक्शन वाला एक माइग्रेशन है।

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