जब कुछ काम न करे, तब भी काम करते रहने के लिए इंजीनियर किया गया।

हमने किसके लिए इंजीनियरिंग की है

हाइपरस्केल क्लाउड आउटेज

प्रमुख क्लाउड प्रदाता डाउन हो जाते हैं। अक्सर नहीं, लेकिन स्पष्ट रूप से, और जब वे ऐसा करते हैं तो वे इंटरनेट के बड़े हिस्से को अपने साथ ले जाते हैं। हमने इस धारणा पर डिज़ाइन किया है कि कोई भी एकल हाइपरस्केलर अंततः वैश्विक स्तर पर खराब दिन का सामना करेगा। जब ऐसा होता है तो Clavitor क्रेडेंशियल प्रदान करना जारी रखता है।

क्षेत्रीय आपदाएँ और काइनेटिक घटनाएँ

एक क्षेत्रीय घटना — डेटा सेंटर पर ड्रोन हमला, समुद्र के नीचे की केबल का कटना, प्राकृतिक आपदा, क्षेत्रीय युद्ध — पूरे क्लाउड क्षेत्र को ऑफ़लाइन कर सकती है। 1 मार्च, 2026 को, एक ही घटना में AWS मिडिल ईस्ट के दोनों क्षेत्र डाउन हो गए थे। हमने इसे एक सबक के रूप में लिया, न कि एक काल्पनिक स्थिति के रूप में। आर्किटेक्चर एक क्षेत्रीय घटना को एक सामान्य विफलता मोड के रूप में मानता है जिसे ग्राहक महसूस नहीं करते हैं।

DNS प्रदाता आउटेज

यदि आपका DNS होस्ट करने वाली कंपनी डाउन हो जाती है, तो आपके स्टैक का हर अन्य हिस्सा स्वस्थ होने के बावजूद आपकी सेवा डाउन हो जाती है। यह Cloudflare, Route 53, हर प्रमुख DNS प्रदाता के लिए सच है। हमने इस पर विचार किया कि जब हमारे DNS प्रदाता का दिन खराब होता है तो क्या होता है।

सर्टिफिकेट अथॉरिटी आउटेज

यदि आपके सर्टिफिकेट को रिन्यू करने की आवश्यकता होने पर आपकी सर्टिफिकेट अथॉरिटी तक नहीं पहुँचा जा सकता, तो आपका TLS डाउन हो जाता है। यदि किसी सर्टिफिकेट अथॉरिटी की सुरक्षा भंग हो जाती है, तो उसके द्वारा जारी किया गया हर सर्टिफिकेट अमान्य हो जाता है। हमने इस पर विचार किया कि जब CA इंफ्रास्ट्रक्चर गड़बड़ करता है तो TLS का क्या होता है।

डोमेन रजिस्ट्रार समस्याएँ

यदि आपका रजिस्ट्रार आपके खाते को निलंबित कर देता है या उसकी सुरक्षा भंग हो जाती है, तो DNS जहाँ भी होस्ट किया गया हो, आपका डोमेन गायब हो जाता है या रीडायरेक्ट हो जाता है। हमने इस पर विचार किया कि यदि हमारा रजिस्ट्रार विफल हो जाता है तो क्या होता है।

TLD ऑपरेटर समस्याएँ

जो संगठन टॉप-लेवल डोमेन (.com, .ai, .io) चलाता है, वह स्वयं विफलता का एक एकल बिंदु है। छोटे TLD कम परिचालन गहराई वाले छोटे संगठनों द्वारा संचालित किए जाते हैं। हमने इस पर विचार किया कि यदि किसी TLD ऑपरेटर का सप्ताह खराब होता है तो क्या होता है।

ईमेल प्रदाता आउटेज

यदि आपका ईमेल प्रदाता डाउन है, तो खाता-पुनर्प्राप्ति कोड नहीं आते, साइनअप पुष्टि नहीं आती, ग्राहक-समर्थन इनबॉक्स डाउन होता है। हमने इस पर विचार किया कि जब हमारा ईमेल प्रदाता तक पहुँच योग्य नहीं होता है तो प्रमाणीकरण और पुनर्प्राप्ति का क्या होता है — और महत्वपूर्ण रूप से, जब ईमेल डाउन होता है तो उत्पाद के बाकी हिस्से का क्या होता है।

SMS / फ़ोन नंबर निर्भरता

कई सेवाएँ ईमेल डाउन होने पर सत्यापन के लिए SMS का सहारा लेती हैं। हमने इस पर विचार किया और ऐसा न करने का फैसला किया। फ़ोन नंबर माँगने से व्यक्तिगत डेटा की एक श्रेणी जुड़ जाती है जिसे हम एकत्र नहीं करना चाहते, ग्राहक SIM-स्वैप हमलों के संपर्क में आते हैं, और एक अन्य वेंडर निर्भरता जुड़ जाती है। हमने एक बेहतर रास्ता चुना।

परिचालन कंट्रोल-प्लेन आउटेज

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

सॉफ़्टवेयर बग्स

एक समान आउटेज का सबसे संभावित एकल कारण हमारे स्वयं के सॉफ़्टवेयर में एक बग है, जिसे एक साथ हर जगह डिप्लॉय किया गया है। जब हर चल रही कॉपी एक ही तरह से क्रैश होती है तो कोई भी भौगोलिक वितरण मदद नहीं करता है। हमने इस पर विचार किया और तदनुसार अपनी डिप्लॉयमेंट प्रथाओं — कैनरी रोलआउट, फास्ट रोलबैक, किल स्विच — को इंजीनियर किया।

खाता-स्तरीय वेंडर कार्रवाइयाँ

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

सहसंबद्ध विफलताएँ

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

विनाशकारी व्यक्तिगत-डेटा निर्भरताएँ

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

परिचालन टीम की पहुँच

एक वॉल्ट कंपनी को किसी घटना के दौरान अपनी स्वयं की टीम द्वारा पहुँच योग्य होने की आवश्यकता होती है। हमने इस पर विचार किया कि जब हमारे स्वयं के ऑपरेटरों के आसपास का इंटरनेट खराब हो जाता है तो हमारी प्रतिक्रिया देने की क्षमता का क्या होता है।

क्रिप्टोग्राफिक क्षितिज

क्रिप्टोग्राफी स्थिर नहीं है। हमने उन सभी क्रिप्टोग्राफिक प्रिमिटिव्स के लिए दीर्घकालिक माइग्रेशन पथ पर विचार किया है जिन पर हम निर्भर करते हैं, जिसमें पोस्ट-क्वांटम भी शामिल है।

हम जिनके खिलाफ सुरक्षा का दावा नहीं करते

हम इस बात को लेकर स्पष्ट हैं कि इंफ्रास्ट्रक्चर इंजीनियरिंग क्या हासिल कर सकती है, इसकी सीमाएँ क्या हैं।

हम इनके बारे में ईमानदार हैं — और हम बाकी हर चीज़ को इस धारणा पर लचीला डिज़ाइन करते हैं कि ये नहीं होंगी।