Neon की लेकबेस आर्किटेक्चर: कैसे स्टेटलेस कंप्यूट और सेल आइसोलेशन AWS आउटेज को मात देते हैं

जब कोई बड़ा क्लाउड प्रोवाइडर किसी क्षेत्रीय कंट्रोल-प्लेन विफलता का सामना करता है, तो आमतौर पर मैनेज्ड डेटाबेस सेवाओं के लिए परिणाम व्यापक अनुपलब्धता होता है: नए इंस्टेंस प्रोविज़न नहीं किए जा सकते, IP पते आवंटित नहीं हो सकते, और फेलओवर तंत्र उन्हीं API पर निर्भर होने के कारण ठप हो जाते हैं जो पहले से डाउन हैं। Neon की लेकबेस आर्किटेक्चर को स्पष्ट रूप से इस निर्भरता श्रृंखला से बचने के लिए डिज़ाइन किया गया था। क्लाउड प्रोवाइडर को एक रीयल-टाइम संसाधन आर्केस्ट्रेटर के रूप में इस्तेमाल करने के बजाय, Neon पहले से क्षमता आवंटित करता है और विफलता के दायरों (फेलियर डोमेन) को अलग-थलग करता है ताकि एक क्षेत्रीय AWS आउटेज स्वचालित रूप से एक क्षेत्रीय Neon आउटेज न बन जाए।

यह लेख उन विशिष्ट आर्किटेक्चरल तंत्रों—स्टेटलेस कंप्यूट, सेल-बेस्ड आइसोलेशन, ज़ोन-रिडंडेंट स्टोरेज, और कम कंट्रोल-प्लेन युग्मन—की जांच करता है जिनका उपयोग Neon अपने प्रभाव के दायरे (ब्लास्ट रेडियस) को सीमित करने के लिए करता है। यह Neon की प्रकाशित घटना समीक्षाओं, आर्किटेक्चर दस्तावेज़ीकरण और तीसरे पक्ष के विश्लेषण पर आधारित है ताकि यह दिखाया जा सके कि मई 2026 के AWS आउटेज (us-east-1 में) के दौरान इन रणनीतियों ने कैसे प्रदर्शन किया, और यह डिज़ाइन की वास्तविक दुनिया की मजबूती के बारे में हमें क्या बताता है।

मूल अंतर्दृष्टि: कंप्यूट की स्थायित्व को कंप्यूट की उपलब्धता से अलग करें

Neon की आर्किटेक्चर एक ऐसे सिद्धांत से शुरू होती है जिसे कहना आसान है लेकिन सुरक्षित रूप से निष्पादित करना कठिन है: कोई भी स्थायी स्थिति (ड्यूरेबल स्टेट) उस कंप्यूट नोड पर नहीं रहनी चाहिए जो Postgres चलाता है। पारंपरिक मैनेज्ड Postgres में, डेटाबेस प्रक्रिया डेटा को लोकल ब्लॉक वॉल्यूम पर लिखती है। यदि इंस्टेंस या उसका अंतर्निहित हार्डवेयर विफल हो जाता है, तो रिकवरी के लिए या तो रेप्लिकेटेड स्थिति के साथ एक हॉट स्टैंडबाय या एक क्रैश रिकवरी प्रक्रिया की आवश्यकता होती है जो विफल नोड के स्टोरेज से WAL (राइट-अहेड लॉग) को फिर से चलाती है। दोनों ही रास्ते क्लाउड प्रोवाइडर की रिप्लेसमेंट इंस्टेंस प्रोविज़न करने और वॉल्यूम अटैच करने की क्षमता पर निर्भर हैं—ठीक वही क्षमता जो क्षेत्रीय आउटेज के दौरान बाधित हो सकती है ।

Neon सभी स्थायी स्थिति को एक अलग, ज़ोन-रिडंडेंट स्टोरेज लेयर में स्थानांतरित करके इस निर्भरता को समाप्त करता है। Neon में Postgres कंप्यूट नोड्स की लोकल डिस्क पर कोई डेटा नहीं होता; वे क्वेरी प्रोसेस करते हैं और राइट-अहेड लॉग (WAL) रिकॉर्ड्स को सैफकीपर (safekeeper) और पेजसर्वर (pageserver) नोड्स के एक बेड़े में स्ट्रीम करते हैं जो हर बदलाव को स्थायी रूप से संग्रहीत करते हैं । इसका मतलब है कि एक कंप्यूट नोड की विफलता से क्वेरी प्रोसेसिंग क्षण भर के लिए रुक जाती है, लेकिन कोई डेटा नष्ट नहीं होता। एक नया कंप्यूट इंस्टेंस उसी स्टोरेज इतिहास से जुड़ सकता है और वहीं से फिर से शुरू कर सकता है जहां पिछले इंस्टेंस ने छोड़ा था, बिना वॉल्यूम पुनः-अटैचमेंट या क्रैश रिकवरी की प्रतीक्षा किए ।

AWS प्रोविज़निंग आउटेज के दौरान व्यावहारिक परिणाम महत्वपूर्ण है: Neon को विफल कंप्यूट नोड्स को बदलने के लिए विफलता के दबाव में EC2 API को कॉल करने की आवश्यकता नहीं है। यह पहले से तैयार (प्री-वार्म्ड) चल रहे इंस्टेंस के पूल से एक प्रतिस्थापन निकाल सकता है और इसे मौजूदा स्टोरेज स्थिति से जोड़ सकता है। क्लाउड प्रोवाइडर की कंट्रोल-प्लेन की खराबी डेटा-उपलब्धता की आपात स्थिति के बजाय एक परिचालन असुविधा बन जाती है।

सेल-बेस्ड आइसोलेशन: एक क्षेत्र का मतलब एक विफलता डोमेन नहीं है

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

मई 2026 के AWS आउटेज के दौरान us-east-1 में, क्लाउड प्रोवाइडर की विफलता ने विशेष रूप से नए इंस्टेंस प्रोविज़न करने और IP पते आवंटित करने की उसकी क्षमता को प्रभावित किया । एकल-सेल आर्किटेक्चर के लिए, यह एक क्षेत्र-व्यापी घटना होती। Neon के सेल-बेस्ड डिज़ाइन में, केवल वे सेल्स प्रभावित हुईं जिन्होंने अपने पूर्व-प्रोविज़न्ड कंप्यूट बफ़र्स को समाप्त कर लिया था। अन्य सेल्स, पहले से आवंटित इंस्टेंस के पर्याप्त बफ़र्स लेकर, बिना किसी रुकावट के काम करती रहीं ।

यह परिणाम एक सोच-समझकर किए गए डिज़ाइन विकल्प को दर्शाता है: सेल्स को इस तरह आकार दिया जाता है कि किसी एक सेल की संसाधन सीमाएं क्षेत्रीय अड़चन न बन सकें। पहले के आर्किटेक्चरल सबक ने इस सोच को मजबूत किया। सेल-बेस्ड आइसोलेशन पर जाने से पहले, Neon प्रति क्षेत्र एक एकल कुबेरनेट्स क्लस्टर संचालित करता था, और परीक्षण ने दिखाया कि EKS आदि मेमोरी सीमाओं, नेटवर्क कॉन्फ़िगरेशन बाधाओं, और कुबेरनेट्स API दर सीमित करने के कारण 10,000 समवर्ती डेटाबेस से अधिक होने पर सेवा में गिरावट आती थी । सेल-बेस्ड आर्किटेक्चर लोड को स्वतंत्र, गैर-अंतःक्रियात्मक कोशिकाओं में विभाजित करके उन एकल-क्लस्टर सीमाओं को पूरी तरह से हटा देता है।

पूर्व-प्रोविज़निंग और कस्टम वर्चुअलाइज़ेशन के माध्यम से क्लाउड प्रोवाइडर निर्भरता को कम करना

Neon का अंतर्निहित क्लाउड प्रोवाइडर के साथ संबंध जानबूझकर एक हाथ की दूरी पर है। जब भी किसी डेटाबेस को शुरू करने की आवश्यकता होती है, तब EC2 API को ऑन-डिमांड कॉल करने के बजाय, Neon बड़े—अक्सर बेयर-मेटल—इंस्टेंस के पूल पूर्व-आवंटित करता है और प्रोविज़निंग आउटेज को अवशोषित करने के लिए बफ़र क्षमता बनाए रखता है । यह बफ़र प्राथमिकता वाले किरायेदारों के लिए एक छोटा वार्म पूल नहीं है; यह इस बात का एक संरचनात्मक घटक है कि सिस्टम कंप्यूट को कैसे शेड्यूल करता है।

इन पूर्व-प्रोविज़न्ड इंस्टेंस के शीर्ष पर, Neon अपनी खुद की वर्टिकल ऑटोस्केलिंग वर्चुअलाइज़ेशन लेयर चलाता है जो एक ही भौतिक होस्ट पर कई Postgres इंस्टेंस को पैक करती है। यह एक साथ दो क्लाउड प्रोवाइडर निर्भरताओं को दरकिनार करता है: VM प्रोविज़निंग API (इंस्टेंस पहले से ही चल रहे हैं) और ब्लॉक-स्टोरेज अटैचमेंट पथ (Neon के कंप्यूट नोड क्लाउड ब्लॉक वॉल्यूम का उपयोग नहीं करते हैं) ।

डेटा स्थायित्व उसी पैटर्न का अनुसरण करता है। सभी डेटाबेस सामग्री Neon की अपनी ज़ोन-रिसीलिएंट स्टोरेज सेवा में रहती है, जो क्लाउड प्रोवाइडर के ब्लॉक डिवाइस के बजाय Amazon S3 या Azure Blob Storage जैसे ऑब्जेक्ट स्टोर्स द्वारा समर्थित है । ऑब्जेक्ट स्टोरेज API के विफलता मोड VM प्रोविज़निंग API से भिन्न होते हैं, और व्यवहार में, क्षेत्रीय कंट्रोल-प्लेन आउटेज के दौरान ऑब्जेक्ट स्टोर स्थायित्व काफी अधिक मजबूत साबित हुआ है। जब कोई पेजसर्वर या सैफकीपर नोड विफल होता है, तो कोई स्थायी स्थिति नष्ट नहीं होती—एक अन्य नोड WAL और ऑब्जेक्ट स्टोरेज से आवश्यक पृष्ठों का पुनर्निर्माण कर सकता है ।

ज़ोन-रिडंडेंट स्टोरेज नींव है, कोई प्रीमियम ऐड-ऑन नहीं

कई मैनेज्ड डेटाबेस सेवाओं में, मल्टी-AZ स्टोरेज रेप्लिकेशन एक भुगतान वाली सुविधा है जिसके लिए स्पष्ट कॉन्फ़िगरेशन की आवश्यकता होती है। Neon में, हर डेटाबेस—मूल्य निर्धारण टियर की परवाह किए बिना—वितरित, ज़ोन-रिडंडेंट ऑब्जेक्ट स्टोरेज द्वारा समर्थित होता है, जिसमें कई उपलब्धता क्षेत्रों (अवेलेबिलिटी ज़ोन) में फैले NVMe SSD कैश होते हैं । यह ज़ोन के पार भौतिक प्रतिकृति की चिंता को एक अलग मुद्दे के रूप में हटा देता है, क्योंकि स्टोरेज लेयर स्वयं स्वाभाविक रूप से प्रतिकृति है।

WAL प्रतिकृति डिज़ाइन ठोस स्थायित्व गारंटी प्रदान करता है: राइट्स को सैफकीपर्स को समकालिक रूप से (सिंक्रोनसली) कोरम आवश्यकता के साथ दोहराया जाता है (छह-तरफा प्रतिकृति के साथ 4/6 राइट कोरम एक प्रकाशित कॉन्फ़िगरेशन है), जिसका अर्थ है कि एक संपूर्ण उपलब्धता क्षेत्र और एक अतिरिक्त प्रतिकृति बिना डेटा हानि के विफल हो सकते हैं । यह सैद्धांतिक मजबूती नहीं है; यह राइट पथ की एक संपत्ति है जिसे क्लाइंट को लेन-देन स्वीकार किए जाने से पहले संतुष्ट होना चाहिए।

विशेष रूप से कंप्यूट उपलब्धता के लिए, साझा स्टोरेज मॉडल एक ऐसा लाभ प्रदान करता है जिसकी बराबरी पारंपरिक प्राथमिक-प्रतिकृति आर्किटेक्चर नहीं कर सकते: क्योंकि सभी कंप्यूट इंस्टेंस एक ही स्थायी स्टोरेज इतिहास साझा करते हैं, एक प्रतिस्थापन कंप्यूट को भौतिक प्रतिकृति के माध्यम से पकड़ने की आवश्यकता नहीं होती है। यह मौजूदा इतिहास से जुड़ता है और वर्कलोड और कैश्ड वर्किंग सेट के आकार के आधार पर सेकंड से लेकर कुछ मिनटों के भीतर क्वेरी परोसना शुरू कर देता है ।

उपलब्धता लक्ष्य और डेटा क्या दिखाता है

Neon की लेकबेस आर्किटेक्चर के लिए प्रकाशित उपलब्धता SLI लगभग 99.93% से 99.96% की सीमा में आते हैं । ये आंकड़े एक ऐसे डिज़ाइन को दर्शाते हैं जहां कंप्यूट विफलताओं को स्टेटलेस नोड्स को बदलकर पुनर्प्राप्त किया जाता है, न कि निष्क्रिय हॉट स्टैंडबाय पर फेलओवर करके, और जहां स्टोरेज स्थायित्व सिंक्रोनस डिस्क मिररिंग के बजाय ऑब्जेक्ट-स्टोर-समर्थित प्रतिकृति के माध्यम से प्राप्त किया जाता है।

Neon का अपना घटना रिकॉर्ड इन लक्ष्यों का एक उपयोगी अंशांकन प्रदान करता है। मई 2025 की एक घटना ने us-east-1 में दो अलग-अलग घटनाओं में डेटाबेस स्टार्ट और क्रिएशन ऑपरेशन के लिए 5.5 घंटे की अनुपलब्धता पैदा की, हालांकि सक्रिय डेटाबेस अप्रभावित रहे । मूल कारण—कंट्रोल प्लेन ओवरलोड और AWS CNI गलत कॉन्फ़िगरेशन द्वारा ट्रिगर कुबेरनेट्स सबनेट में IP पतों की कमी—ने एक स्केलिंग सीमा को उजागर किया जिसे सेल-बेस्ड आर्किटेक्चर को बाद में रोकने के लिए डिज़ाइन किया गया था । इससे पहले, अगस्त 2024 में, us-east-1 में एक पेजसर्वर आउटेज ने EC2 इंस्टेंस विफलता के बाद लगभग 0.4% ग्राहक परियोजनाओं को दो घंटे तक प्रभावित किया; क्योंकि पेजसर्वर S3 द्वारा समर्थित एक स्थानीय डिस्क कैश के रूप में कार्य करते हैं, पेजसर्वर के नुकसान का मतलब स्थायी डेटा हानि के बजाय अस्थायी अनुपलब्धता था ।

ये घटनाएं रेखांकित करती हैं कि स्टेटलेस कंप्यूट और साझा स्टोरेज विफलताओं की गंभीरता को कम करते हैं लेकिन उन्हें पूरी तरह से समाप्त नहीं करते। आर्किटेक्चर के मजबूती गुण—कंप्यूट विफलताओं से कोई डेटा हानि नहीं, पुनः-अटैचमेंट के माध्यम से स्वचालित पुनर्प्राप्ति, सेल-बद्ध ब्लास्ट रेडियस—वास्तविक विफलता स्थितियों के तहत कायम रहते हैं, लेकिन सिस्टम सॉफ़्टवेयर दोषों, संसाधन की कमी, या क्लाउड प्रोवाइडर निर्भरताओं से प्रतिरक्षित नहीं है जिन्हें अभी तक पूरी तरह से अलग नहीं किया गया है (जैसे IP पता आवंटन)।

मजबूती परीक्षण: Neon डिज़ाइन को कैसे मान्य करता है

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

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

सर्वरलेस Postgres का मूल्यांकन करने वाली टीमों के लिए इसका क्या अर्थ है

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

यह आर्किटेक्चर क्लाउड निर्भरता के एक ईमानदार लेखा-जोखा को भी बल देता है। कोई भी डेटाबेस सेवा वास्तव में अपने अंतर्निहित क्लाउड प्रोवाइडर से स्वतंत्र नहीं है, लेकिन युग्मन की डिग्री बहुत भिन्न होती है। Neon का क्षमता को पूर्व-प्रोविज़न करने, अपनी खुद की वर्चुअलाइज़ेशन लेयर का उपयोग करने और डेटा को ब्लॉक वॉल्यूम के बजाय ऑब्जेक्ट स्टोरेज में संग्रहीत करने का निर्णय क्लाउड प्रोवाइडर API के सतही क्षेत्र को कम करता है जो डेटाबेस टियर के कार्य करने के लिए उपलब्ध होना चाहिए। उस संकीर्ण निर्भरता सतह ने मई 2026 के AWS आउटेज के दौरान लाभांश का भुगतान किया, जब पर्याप्त पूर्व-प्रोविज़न्ड बफ़र्स वाली सेल्स ने एक ऐसी विफलता के माध्यम से काम करना जारी रखा जो अधिक कसकर युग्मित आर्किटेक्चर के लिए क्षेत्र-व्यापी होती।

सर्वरलेस इंफ्रास्ट्रक्चर पर निर्माण करने वाली टीमों के लिए, Neon का दृष्टिकोण दर्शाता है कि ब्लास्ट-रेडियस नियंत्रण कोई बाद का विचार नहीं है—यह आर्किटेक्चरल निर्णयों का एक उत्पाद है जो स्टोरेज-कंप्यूट सीमा और विफलता-डोमेन संरचना पर एक आउटेज होने से बहुत पहले किए जाते हैं।