हम Roblox के इंफ्रास्ट्रक्चर को कैसे अधिक कुशल और लचीला बना रहे हैं

जैसे-जैसे पिछले 16+ वर्षों में रॉब्लॉक्स बढ़ा है, वैसे-वैसे उस तकनीकी बुनियादी ढांचे का पैमाना और जटिलता भी बढ़ी है जो लाखों इमर्सिव 3डी सह-अनुभवों का समर्थन करता है। पिछले दो वर्षों में हम जिन मशीनों का समर्थन करते हैं, उनकी संख्या तीन गुना से भी अधिक हो गई है, जो 30 जून, 2021 को लगभग 36,000 थी, और आज यह लगभग 145,000 हो गई है। दुनिया भर के लोगों के लिए इन हमेशा-चालू रहने वाले अनुभवों का समर्थन करने के लिए 1,000 से अधिक आंतरिक सेवाओं की आवश्यकता होती है। लागत और नेटवर्क विलंबता को नियंत्रित करने में हमारी मदद करने के लिए, हम इन मशीनों को एक कस्टम-निर्मित और हाइब्रिड निजी क्लाउड इंफ्रास्ट्रक्चर के हिस्से के रूप में तैनात और प्रबंधित करते हैं जो मुख्य रूप से ऑन-प्रिमाइसेस पर चलता है।  

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

अक्टूबर, 2021 में, हमने एक सिस्टम-व्यापी आउटेज का अनुभव किया। इसकी शुरुआत एक डेटा सेंटर के एक घटक में एक समस्या के साथ छोटी थी। लेकिन जब हम इसकी जांच कर रहे थे तो यह तेजी से फैल गया और अंततः 73 घंटे के आउटेज का कारण बना। उस समय, हमने जो हुआ उसकी जानकारी और इस समस्या से मिली हमारी कुछ शुरुआती सीखें साझा की थीं। तब से, हम उन सीखों का अध्ययन कर रहे हैं और अपने बुनियादी ढांचे की लचीलापन बढ़ाने के लिए काम कर रहे हैं, ताकि उन प्रकार की विफलताओं के प्रति यह अधिक मजबूत हो सके जो सभी बड़े पैमाने के सिस्टम में अत्यधिक ट्रैफ़िक स्पाइक, मौसम, हार्डवेयर विफलता, सॉफ़्टवेयर बग, या सिर्फ़ इंसानों की गलतियों जैसे कारकों के कारण होती हैं। जब ये विफलताएं होती हैं, तो हम यह कैसे सुनिश्चित करें कि एकल घटक, या घटकों के समूह में कोई समस्या पूरे सिस्टम में न फैले? पिछले दो वर्षों से यह प्रश्न हमारा ध्यान केंद्रित रहा है और हालांकि यह काम जारी है, अब तक हमने जो किया है, उसका लाभ पहले से ही मिल रहा है। उदाहरण के लिए, 2022 की पहली छमाही की तुलना में 2023 की पहली छमाही में, हमने प्रति माह 125 मिलियन एंगेजमेंट घंटे बचाए। आज, हम अपने द्वारा पहले से किए गए काम के साथ-साथ एक अधिक लचीली अवसंरचना प्रणाली बनाने के लिए अपनी दीर्घकालिक दृष्टि भी साझा कर रहे हैं।

बैकस्टॉप का निर्माण

बड़े पैमाने के बुनियादी ढांचे की प्रणालियों में, छोटे स्तर की विफलताएं दिन में कई बार होती हैं। यदि किसी एक मशीन में कोई समस्या आ जाती है और उसे सेवा से बाहर करना पड़ता है, तो यह प्रबंधनीय है क्योंकि अधिकांश कंपनियाँ अपनी बैक-एंड सेवाओं के कई उदाहरण बनाए रखती हैं। इसलिए जब एक उदाहरण विफल हो जाता है, तो अन्य उसके कार्यभार को संभाल लेते हैं। इन बार-बार होने वाली विफलताओं को दूर करने के लिए, अनुरोधों को आम तौर पर स्वचालित रूप से पुनः प्रयास करने के लिए सेट किया जाता है यदि उन्हें कोई त्रुटि मिलती है।

यह तब चुनौतीपूर्ण हो जाता है जब कोई सिस्टम या व्यक्ति बहुत आक्रामक रूप से पुनः प्रयास करता है, जो उन छोटी-छोटी विफलताओं को पूरे इंफ्रास्ट्रक्चर में अन्य सेवाओं और सिस्टमों तक फैलाने का एक तरीका बन सकता है। यदि नेटवर्क या कोई उपयोगकर्ता लगातार पुनः प्रयास करता है, तो यह अंततः उस सेवा के हर उदाहरण, और संभावित रूप से अन्य सिस्टमों को भी, वैश्विक स्तर पर ओवरलोड कर देगा। हमारी 2021 की आउटेज का कारण कुछ ऐसा था जो बड़े पैमाने के सिस्टम में काफी आम है: एक खराबी छोटी शुरुआत करती है और फिर सिस्टम में फैल जाती है, इतनी तेजी से बढ़ जाती है कि सब कुछ बंद होने से पहले उसे ठीक करना मुश्किल हो जाता है। 

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

सेलुलर इंफ्रास्ट्रक्चर की ओर

हमारी अगली प्राथमिकता प्रत्येक डेटा सेंटर के अंदर मजबूत ब्लास्ट वॉल बनाना थी ताकि पूरे डेटा सेंटर के विफल होने की संभावना को कम किया जा सके। सेल (कुछ कंपनियाँ उन्हें क्लस्टर कहती हैं) मूल रूप से मशीनों का एक सेट होते हैं और इन्हीं से हम ये दीवारें बना रहे हैं। हम अतिरिक्त रिडंडेंसी के लिए सेलों के भीतर और उनके बीच दोनों जगह सेवाओं को प्रतिकृति बनाते हैं। अंततः, हम चाहते हैं कि Roblox पर सभी सेवाएँ सेलों में चलें ताकि वे मजबूत ब्लास्ट वॉल और रिडंडेंसी दोनों का लाभ उठा सकें। यदि कोई सेल अब काम नहीं कर रहा है, तो उसे सुरक्षित रूप से निष्क्रिय किया जा सकता है। सेलों के बीच प्रतिकृति (replication) सेवा को तब तक चलते रहने में सक्षम बनाती है जब तक कि सेल की मरम्मत हो रही होती है। कुछ मामलों में, सेल की मरम्मत का मतलब सेल का पूरा पुनः प्रावधान (reprovisioning) हो सकता है। पूरे उद्योग में, एक व्यक्तिगत मशीन, या मशीनों के एक छोटे समूह को मिटाना और पुनः प्रावधान करना काफी आम है, लेकिन पूरे सेल के लिए ऐसा करना, जिसमें ~1,400 मशीनें होती हैं, आम नहीं है। 

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

वर्तमान में सभी सेवाएँ इन आवश्यकताओं को पूरा नहीं करती हैं, इसलिए हमने सेवा मालिकों को जहाँ संभव हो वहाँ इन्हें पूरा करने में मदद करने के लिए काम किया है, और हमने नए उपकरण बनाए हैं ताकि जब तैयार हों तो सेवाओं को सेल में माइग्रेट करना आसान हो सके। उदाहरण के लिए, हमारा नया डिप्लॉयमेंट टूल स्वचालित रूप से सेलों में एक सेवा डिप्लॉयमेंट को "स्ट्राइप्स" करता है, ताकि सेवा मालिकों को प्रतिकृति रणनीति के बारे में सोचना न पड़े। इस स्तर की सख्ती माइग्रेशन प्रक्रिया को बहुत अधिक चुनौतीपूर्ण और समय लेने वाली बनाती है, लेकिन दीर्घकालिक लाभ एक ऐसी प्रणाली होगा जहाँ: 

• किसी विफलता को नियंत्रित करना और उसे अन्य सेलों में फैलने से रोकना कहीं अधिक आसान है; 
• हमारे इंफ्रास्ट्रक्चर इंजीनियर अधिक कुशल हो सकते हैं और तेज़ी से काम कर सकते हैं; और 
• जो इंजीनियर उत्पाद-स्तर की सेवाएँ बनाते हैं, जिन्हें अंततः सेलों में तैनात किया जाता है, उन्हें यह जानने या चिंता करने की आवश्यकता नहीं है कि उनकी सेवाएँ किन सेलों में चल रही हैं।

बड़ी चुनौतियों का समाधान

जिस तरह आग के दरवाजों का उपयोग लपटों को रोकने के लिए किया जाता है, उसी तरह सेल हमारे बुनियादी ढांचे के भीतर मजबूत विस्फोट-रोधी दीवारों के रूप में कार्य करते हैं, ताकि किसी एक सेल के भीतर विफलता पैदा करने वाली किसी भी समस्या को रोकने में मदद मिल सके। अंततः, Roblox को बनाने वाली सभी सेवाएं सेलों के अंदर और उनके पार रिडंडेंटली तैनात की जाएंगी। एक बार यह काम पूरा हो जाने पर, समस्याएं अभी भी इतनी व्यापक रूप से फैल सकती हैं कि एक पूरे सेल को निष्क्रिय कर दें, लेकिन किसी समस्या के उस सेल से आगे फैलना अत्यंत कठिन होगा। और यदि हम सेलों को परस्पर-विन्यासयोग्य बनाने में सफल हो जाते हैं, तो रिकवरी काफी तेज होगी क्योंकि हम एक अलग सेल पर फेल-ओवर कर सकेंगे और समस्या को अंतिम उपयोगकर्ताओं को प्रभावित करने से रोक सकेंगे। 

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

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

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

हमेशा चालू रहने वाले इन्फ्रास्ट्रक्चर का माइग्रेशन

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

हालांकि, हमारे पास कुछ अतिरिक्त मशीनें थीं जो भविष्य में होने वाली वृद्धि की उम्मीद में खरीदी गई थीं। शुरुआत में, हमने उन मशीनों का उपयोग करके नए सेल बनाए, फिर उन पर वर्कलोड माइग्रेट किए। हम दक्षता के साथ-साथ विश्वसनीयता को भी महत्व देते हैं, इसलिए जब हमारे पास "अतिरिक्त" मशीनें खत्म हो गईं, तो हमने और मशीनें खरीदने के बजाय उन मशीनों को मिटाकर और फिर से तैयार करके (wiping and reprovisioning) और सेल बनाए, जिनसे हमने पहले वर्कलोड माइग्रेट किए थे। फिर हमने उन फिर से तैयार की गई मशीनों पर वर्कलोड माइग्रेट किए, और यह प्रक्रिया फिर से शुरू की। यह प्रक्रिया जटिल है—जैसे-जैसे मशीनों को बदला जाता है और वे सेल बनाने के लिए खाली होती हैं, वे एक आदर्श, व्यवस्थित तरीके से खाली नहीं हो रही हैं। वे डेटा हॉल में भौतिक रूप से बिखरी हुई हैं, जिससे हमें उन्हें टुकड़ों में प्रोविजन करना पड़ता है, जिसके लिए हार्डवेयर स्थानों को बड़े पैमाने पर भौतिक विफलता डोमेन के साथ संरेखित रखने के लिए हार्डवेयर-स्तर की डीफ्रैगमेंटेशन प्रक्रिया की आवश्यकता होती है। 

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

आज, लगभग 30,000 मशीनों को सेल्स द्वारा प्रबंधित किया जा रहा है। यह हमारे कुल बेड़े का केवल एक छोटा सा हिस्सा है, लेकिन अब तक यह बिना किसी नकारात्मक प्रभाव के एक बहुत ही सुचारू संक्रमण रहा है। हमारा अंतिम लक्ष्य है कि हमारी प्रणालियाँ हर महीने 99.99 प्रतिशत उपयोगकर्ता अपटाइम हासिल करें, जिसका अर्थ है कि हम जुड़ाव के घंटों में 0.01 प्रतिशत से अधिक व्यवधान नहीं डालेंगे। उद्योग-व्यापी रूप से, डाउनटाइम को पूरी तरह से समाप्त नहीं किया जा सकता, लेकिन हमारा लक्ष्य किसी भी Roblox डाउनटाइम को इस हद तक कम करना है कि वह लगभग ध्यान न देने योग्य हो।

जैसे-जैसे हम विस्तार कर रहे हैं, भविष्य के लिए तैयारी

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

सारांश में, आज तक, हमने: 

• दूसरा डेटा सेंटर बनाया और सक्रिय/निष्क्रिय स्थिति सफलतापूर्वक हासिल की। 
• हमारे सक्रिय और निष्क्रिय डेटा सेंटरों में सेल बनाए और अपनी बैक-एंड सेवा ट्रैफ़िक का 70 प्रतिशत से अधिक सफलतापूर्वक इन सेल में माइग्रेट किया।
• हमारे शेष बुनियादी ढांचे को माइग्रेट करना जारी रखते हुए सभी सेलों को एकसमान बनाए रखने के लिए आवश्यक आवश्यकताओं और सर्वोत्तम प्रथाओं को लागू किया है। 
• सेलों के बीच मजबूत "ब्लास्ट वॉल" बनाने की एक सतत प्रक्रिया शुरू की है। 

जैसे-जैसे ये सेल अधिक परस्पर प्रतिस्थापन योग्य होते जाएंगे, सेलों के बीच क्रॉसटॉक कम हो जाएगा। यह हमें निगरानी, समस्या निवारण, और यहां तक कि वर्कलोड को स्वचालित रूप से स्थानांतरित करने के आसपास स्वचालन बढ़ाने के मामले में कुछ बहुत ही दिलचस्प अवसर प्रदान करता है। 

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