बैकएंड इंटरव्यू: आप डेटाबेस और कैश को कंसिस्टेंट कैसे रखते हैं?

प्रॉम्प्ट और लागू संदर्भ

PostgreSQL प्रोडक्ट डेटा के लिए सोर्स ऑफ़ ट्रुथ है। Redis product_id द्वारा कुंजीकृत (keyed) एक डिस्प्ले स्नैपशॉट स्टोर करता है। यह सिस्टम लगभग 2,000 एक्टिव प्रोडक्ट्स पर प्रति सेकंड लगभग 20,000 रीड्स और 500 राइट्स को संभालता है। नाम, इमेज और डिस्प्ले कॉपी अधिकतम 5 सेकंड के लिए पुराने हो सकते हैं। इन्वेंट्री कटौती, चेकआउट की कीमतें, अनुमतियां और बैलेंस उस कैश अनुबंध से बाहर हैं क्योंकि वे व्यावसायिक शुद्धता निर्धारित करते हैं।

कैश-असाइड रीड, अपडेट और इनवैलिडेशन पाथ्स डिज़ाइन करें। इन मामलों को कवर करें:

• डेटाबेस कमिट हो जाता है, लेकिन कैश प्रविष्टि को हटाने से पहले प्रोसेस क्रैश हो जाता है;
• एक रीडर पुराना डेटाबेस वर्ज़न प्राप्त करता है और राइटर द्वारा कैश को इनवैलिडेट करने के बाद ही अपना फ़िल पूरा करता है;
• एक फ़िल एसिंक्रोनस डेटाबेस रेप्लिक से लैगिंग डेटा पढ़ता है;
• इनवैलिडेशन इवेंट्स डुप्लिकेट, रीऑर्डर या बैकलॉग हो जाते हैं;
• Redis अस्थायी रूप से अनुपलब्ध है;
• प्रोडक्ट टीम चाहती है कि "अधिकतम 5 सेकंड पुराना" एक मॉनिटर किया गया और परीक्षण किया गया अनुबंध हो।

थ्रूपुट, एक्टिव-की काउंट और 5-सेकंड का बजट इंटरव्यू की धारणाएं हैं, सार्वभौमिक सेटिंग्स नहीं। वर्तमान सार्वजनिक 2026 बैकएंड और सीनियर कैशिंग इंटरव्यू सामग्री स्पष्ट रूप से कैश-असाइड, राइट्स के बाद इनवैलिडेशन और कैश कंसिस्टेंसी को कवर करती है। मुख्य कौशल डेटाबेस कमिट के बाद बैकएंड प्रोटोकॉल और विफलता शब्दार्थ (failure semantics) है, इसलिए श्रेणी backend है। यह किसी हॉट की (hot key) के एक्सपायर होने पर कैश स्टैम्पीड को रोकने से अलग है: स्टैम्पीड नियंत्रण समवर्ती सोर्स रीड्स को सीमित करता है, जबकि यह समस्या पूछती है कि कोई पुराना मान किसी राइट के बाद कब तक बना रह सकता है, वह क्यों बना रहता है, और वह कितने समय तक रह सकता है।

इंटरव्यूअर क्या मूल्यांकन करता है

पहला, क्या उम्मीदवार कोई पैटर्न चुनने से पहले कंसिस्टेंसी लक्ष्य को परिभाषित कर सकता है? "डेटाबेस और कैश हमेशा कंसिस्टेंट होते हैं" यह निर्दिष्ट नहीं करता कि कौन से रीड परिणाम वैध हैं। एक मजबूत उत्तर डिस्प्ले डेटा के लिए 5-सेकंड के बाउंडेड स्टेलनेस, अपडेट करने वाले कॉलर के लिए रीड-योर-राइट्स (read-your-writes), और इन्वेंट्री या अनुमतियों के लिए आधिकारिक (authoritative) रीड्स को अलग करता है। उन अनुबंधों के लिए अलग-अलग पाथ्स की आवश्यकता होती है।

दूसरा, क्या वे राइट क्रम को समझा सकते हैं? एक सामान्य कैश-असाइड राइट पाथ डेटाबेस को कमिट करता है और फिर कैश प्रविष्टि को हटाता है। पहले हटाना एक स्पष्ट रेस कंडीशन बनाता है: इन दोनों ऑपरेशनों के बीच एक रीडर मिस होता है, पुराना डेटाबेस मान प्राप्त करता है, और इसे वापस कैश में डाल देता है। डेटाबेस-पहले अभी भी एक एटॉमिक डुअल राइट नहीं है। एक संक्षिप्त कमिट-टू-डिलीट विंडो होती है, और एक असफल डिलीट अपने टीटीएल (TTL) तक एक पुरानी प्रविष्टि को छोड़ सकता है।

तीसरा, क्या वे लेट स्टेल-फ़िल टाइमलाइन बना सकते हैं? एक रीडर डेटाबेस अपडेट से पहले वर्ज़न 41 प्राप्त कर सकता है। फिर एक राइटर वर्ज़न 42 कमिट करता है और कैश को हटा देता है, जिसके बाद पुराना रीडर वर्ज़न 41 को वापस रख देता है। केवल कैश्ड मान में वर्ज़न जोड़ना हमेशा पर्याप्त नहीं होता है। डिलीट करने के बाद तुलना करने के लिए कोई कैश्ड वर्ज़न नहीं होता है, इसलिए "सोर्स वर्ज़न कम से कम कैश्ड वर्ज़न होने पर लिखें" जैसा नियम 41 को स्वीकार कर लेता है। डिज़ाइन को एक वर्ज़न फ़ेंस की आवश्यकता होती है जो मान हटाए जाने के बाद भी जीवित रहे, एक फ़िल लीज जिसे राइट्स इनवैलिडेट करते हैं, या फ़िल से पहले एक अन्य आधिकारिक वर्ज़न चेक की आवश्यकता होती है।

चौथा, क्या वे विश्वसनीय इनवैलिडेशन को एक सीमित समय सीमा से अलग कर सकते हैं? एक ट्रांज़ैक्शनल आउटबॉक्स या चेंज डेटा कैप्चर उस गैप को बंद कर देता है जिसमें डेटाबेस कमिट होता है लेकिन कोई इनवैलिडेशन संदेश ड्यूरेबली रिकॉर्ड नहीं होता है। एट-लीस्ट-वन्स डिलीवरी और इडेम्पोटेंट डिलीशन डुप्लिकेट्स को सहन करते हैं। पुनः प्रयास (retries) अंतिम प्रोसेसिंग (eventual processing) स्थापित करते हैं; वे 5 सेकंड के भीतर पूरा होने को साबित नहीं करते हैं। बाउंडेड स्टेलनेस को अतिरिक्त रूप से एक हार्ड टीटीएल, एक इनवैलिडेशन-लैग गेट, या एक ऐसे नियम की आवश्यकता होती है जो पाइपलाइन के बजट से अधिक होने पर कैश को बायपास कर देता है।

पांचवां, क्या वे सोर्स ऑफ़ ट्रुथ, डेटाबेस रेप्लिकास और परिचालन सत्यापन (operational verification) को संभाल सकते हैं? एक सफल डेटाबेस कमिट नया तथ्य बनाता है। लैगिंग रेप्लिक से फ़िल करना सही इनवैलिडेशन के बाद एक पुराना मान फिर से ला सकता है। एक मजबूत उत्तर फ़िल सोर्स को सीमित करता है, इवेंट और कैश वर्ज़न को देखता है, और केवल कैश हिट रेट की रिपोर्ट करने के बजाय नियंत्रित समवर्ती टाइमलाइन और विफलताओं का परीक्षण करता है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• कंसिस्टेंसी अनुबंध क्या है? यदि 5 सेकंड तक के पुरानेपन की अनुमति है, तो एसिंक्रोनस इनवैलिडेशन और एक हार्ड डेडलाइन काम कर सकती है। यदि रीड-योर-राइट्स की आवश्यकता है, तो राइटर के बाद के अनुरोधों को संक्षेप में कैश को बायपास करना चाहिए या न्यूनतम वर्ज़न ले जाना चाहिए। यदि कोई पुराना रीड वैध नहीं है, तो आधिकारिक स्टोर पढ़ें या आवश्यक कंसिस्टेंसी अनुबंध वाले स्टोरेज पाथ का उपयोग करें।
• कौन से फ़ील्ड्स अपरिवर्तनीय क्रियाओं को अधिकृत करते हैं? एक डिस्प्ले नाम या इमेज पुरानी हो सकती है। इन्वेंट्री सत्यापन, छूट पात्रता, अनुमतियां, बैलेंस और चार्ज की गई कीमतों को कैश्ड स्नैपशॉट को आधिकारिक नहीं मानना चाहिए। यदि वे फ़ील्ड एक ही ऑब्जेक्ट साझा करते हैं, तो रीड अनुबंधों को विभाजित करें या महत्वपूर्ण कार्रवाई के दौरान आधिकारिक स्थिति को दोबारा पढ़ें।
• 5-सेकंड की घड़ी कब शुरू होती है? इस प्रॉम्प्ट में यह डेटाबेस कमिट से शुरू होती है। यदि यह तब शुरू होती है जब मान Redis में प्रवेश करता है, तो एक रेप्लिक जो पहले से ही 4 सेकंड पीछे है, उसे 5 और सेकंड के लिए कैश किया जा सकता है, जिससे वास्तविक डेटा आयु लगभग 9 सेकंड हो जाती है।
• क्या एक ही सर्विस हर राइट पाथ को नियंत्रित करती है? बैच जॉब्स, एडमिन टूल्स और अन्य सर्विसेज API-स्तरीय DEL को बायपास कर सकती हैं। एक ही डेटाबेस ट्रांज़ैक्शन में एक इनवैलिडेशन रिकॉर्ड डालें या डेटाबेस लॉग से प्रत्येक समर्थित परिवर्तन को कैप्चर करें।
• क्या मिस होने पर प्राइमरी से फ़िल होता है या रेप्लिक से? रेप्लिक-लैग सीमा स्थापित करें और यह भी कि क्या सत्र-स्तरीय (session-level) रीड-योर-राइट्स मौजूद हैं। यदि रेप्लिक को बजट के भीतर वर्तमान साबित नहीं किया जा सकता है, तो पहले पोस्ट-इनवैलिडेशन फ़िल को प्राइमरी का उपयोग करना चाहिए या कॉलर के न्यूनतम वर्ज़न जितना नया परिणाम प्राप्त करना चाहिए।
• डेटाबेस कितना फ़िल ट्रैफ़िक सहन कर सकता है? 5-सेकंड के टीटीएल के साथ, 2,000 समान रूप से समाप्त होने वाली एक्टिव कीज़ जिन्हें पढ़ा जाता है, औसतन प्रति सेकंड लगभग 2000 / 5 = 400 फ़िल्स उत्पन्न करती हैं। एक्सेस वितरण, जिटर और अनुरोध कोएलेसिंग (request coalescing) वास्तविक मूल्य को बदल देते हैं। यदि डेटाबेस में उस बजट की कमी है, तो टीटीएल को छोटा करने से जादुई रूप से कंसिस्टेंसी संतुष्ट नहीं होती है।
• जब Redis अनुपलब्ध हो, तो फ्रेशनेस अधिक महत्वपूर्ण है या उपलब्धता? डिस्प्ले डेटा एक स्पष्ट पुराने-मान की सीमा के भीतर डिग्रेड हो सकता है। आधिकारिक फ़ील्ड्स को एक संरक्षित सोर्स पाथ का उपयोग करना चाहिए। यदि डेटाबेस सभी मिसेस को अवशोषित नहीं कर सकता है, तो अनबाउंडेड फ़ॉलबैक के बजाय दर सीमाएं (rate limits), बल्कहेड्स और स्पष्ट विफलताओं को लागू करें।

30-सेकंड उत्तर ढांचा

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

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

चरण-दर-चरण गहन विश्लेषण

चरण 1: कंसिस्टेंसी को रीड-रिज़ल्ट अनुबंध में बदलें

कैश पैटर्न चुनने से पहले व्यावसायिक परिणाम के आधार पर डेटा को विभाजित करें:

यह वर्गीकरण बाकी डिज़ाइन को संचालित करता है। एक कैश एक पुनर्निर्माण योग्य प्रतिलिपि को गति देता है। इसे किसी ऐसे मान का उपयोग करके इन्वेंट्री कटौती को अधिकृत नहीं करना चाहिए जिसे विलंबित, निष्कासित या खोया जा सकता है। 99.9% हिट रेट इस बारे में कुछ नहीं बताता कि क्या शेष 0.1% ओवरसेलिंग या अनधिकृत पहुंच उत्पन्न करता है।

प्रत्येक कैश प्रविष्टि को कम से कम एक सोर्स वर्ज़न और समय की जानकारी की आवश्यकता होती है। निम्नलिखित एक स्यूडोसंरचना (pseudostructure) है, किसी विशेष भाषा में निष्पादन योग्य प्रकार नहीं:

ProductCacheEntry {
  value
  source_version
  source_committed_at
  cached_at
}

source_committed_at वास्तविक पुरानी आयु मापता है; cached_at केवल यह बताता है कि Redis को मान कब प्राप्त हुआ। सोर्स वर्ज़न एक मोनोटोनिक रूप से बढ़ती पंक्ति वर्ज़न, एक कमिट अनुक्रम, या एक निश्चित क्रम के साथ एक अन्य डोमेन वर्ज़न हो सकता है। यदि मान टाई हो सकते हैं या घड़ियाँ ड्रिफ्ट हो सकती हैं, तो केवल वॉल-क्लॉक टाइमस्टैम्प एक खराब ऑर्डरिंग प्रमाण है।

चरण 2: बुनियादी कैश-असाइड पाथ स्थापित करें

रीड पाथ केवल तभी कैश हिट लौटाता है जब यह कॉलर के न्यूनतम वर्ज़न और स्टेल-एज बजट दोनों को संतुष्ट करता है। मिस होने पर, समान product_id के लिए फ़िल्स को कोएलेस करें ताकि 20,000 रीड्स एक साथ डेटाबेस तक न पहुंचें। एक वर्ज़न वाली पंक्ति प्राप्त करें, फिर एक सशर्त Redis राइट का प्रयास करें। निम्नलिखित फ्लो स्यूडोकोड है:

read(product_id, min_version = none):
  entry = cache.get(product_id)
  if entry satisfies age_budget and min_version:
    return entry.value

  return singleflight(product_id):
    recheck cache
    row = read_authoritative_version(product_id)
    conditional_fill(product_id, row)
    return row.value

राइट पाथ बिज़नेस पंक्ति को अपडेट करता है और उसी PostgreSQL ट्रांज़ैक्शन में एक आउटबॉक्स रिकॉर्ड सम्मिलित करता है। केवल एक सफल COMMIT बिज़नेस परिवर्तन को अन्य ट्रांज़ैक्शन्स के लिए दृश्यमान और ड्यूरेबल बनाता है। एप्लिकेशन तब एक तेज़ इनवैलिडेशन प्रयास करता है। एक अलग रिले या CDC उपभोक्ता पुनः प्रयास और मरम्मत के लिए ड्यूरेबल इनवैलिडेशन इवेंट को प्रोसेस करता है। राइट-पाथ स्यूडोकोड है:

transaction:
  row = update product and increment source_version
  insert outbox(product_id, source_version, committed_at)
commit

best_effort_invalidate(product_id, source_version)
return committed source_version

प्रत्यक्ष इनवैलिडेशन सामान्य स्थिति की विंडो को कम करता है। जब कमिट के बाद प्रोसेस क्रैश हो जाता है, तो आउटबॉक्स संदेश-हानि के गैप को बंद कर देता है। यदि दोनों पाथ एक ही परिवर्तन को संभालते हैं, तो डिलीशन इडेम्पोटेंट होना चाहिए: समान सोर्स वर्ज़न को दोबारा प्राप्त करने से कोई नया व्यावसायिक दुष्प्रभाव (side effect) नहीं हो सकता है।

चरण 3: तीन रेस विंडो का स्पष्ट विश्लेषण करें

विंडो 1: डेटाबेस कमिट और कैश डिलीशन के बीच।

W: COMMIT version 42
R: read cached version 41
W: DEL cache key

रीडर संक्षेप में वर्ज़न 41 देखता है, जो बाउंडेड स्टेलनेस के तहत वैध है। यदि कोई पुराना परिणाम स्वीकार्य नहीं है, तो राइट रिस्पॉन्स लौटाने से पहले कैश ऑपरेशन की प्रतीक्षा करना अभी भी हर नेटवर्क अस्पष्टता को हल नहीं करता है। एक स्पष्ट अनुबंध महत्वपूर्ण रीड को सोर्स ऑफ़ ट्रुथ पर भेजता है या कॉलर को min_version=42 की आवश्यकता की अनुमति देता है।

विंडो 2: डेटाबेस कमिट होता है लेकिन इनवैलिडेशन नहीं चलता है।

W: COMMIT version 42 plus outbox record
W: process crashes before DEL
R: cache still contains version 41
relay: retries invalidation for version 42

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

विंडो 3: इनवैलिडेशन के बाद एक पुराना रीड फ़िल करता है।

R: cache miss; captures generation 7
R: reads database version 41
W: commits version 42
W: advances generation to 8 and deletes cache value
R: tries to fill version 41 with generation 7; rejected

यह अक्सर छूट जाने वाली रेस है। यदि डिज़ाइन केवल मान को हटाता है, तो version 41 >= no version पास हो जाता है और पुराने डेटा को पुनर्जीवित करता है। एक समाधान मान को उसके फ़ेंस से अलग करता है। इनवैलिडेशन एक अल्पकालिक जनरेशन या न्यूनतम-सोर्स-वर्ज़न की को आगे बढ़ाता है। एक Redis स्क्रिप्ट एटॉमिक रूप से जांचती है कि फ़िल जनरेशन अभी भी मिस समय पर कैप्चर की गई जनरेशन से मेल खाती है और सोर्स वर्ज़न मान लिखने से पहले न्यूनतम को पूरा करता है। Redis Cluster में, मान और फ़ेंस कीज़ को एक ही हैश स्लॉट का उपयोग करना चाहिए ताकि स्क्रिप्ट दोनों को एटॉमिक रूप से एक्सेस कर सके। दूसरा कार्यान्वयन एक मिस लीज जारी करता है जिसे डेटाबेस अपडेट इनवैलिडेट कर देता है। फ़िल करने से पहले प्राइमरी वर्ज़न को दोबारा पढ़ना मदद कर सकता है, लेकिन यह एक डेटाबेस रीड जोड़ता है और फिर भी चेक और कैश राइट के बीच एक परिभाषित एटॉमिक सीमा की आवश्यकता होती है।

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

चरण 4: डिलीवरी को बढ़ा-चढ़ाकर बताए बिना इनवैलिडेशन को रिकवरेबल बनाएं

आउटबॉक्स पंक्ति और बिज़नेस अपडेट एक ही ट्रांज़ैक्शन में लिखे जाते हैं। एक रिले इनवैलिडेशन को एक ड्यूरेबल चैनल पर भेजता है। उपभोक्ता प्रत्येक product_id के लिए उच्चतम देखे गए वर्ज़न को ट्रैक कर सकता है और इन नियमों को लागू कर सकता है:

1. उच्चतम देखे गए वर्ज़न से नीचे के आउट-ऑफ़-ऑर्डर इवेंट को इडेम्पोटेंट रूप से स्वीकार (acknowledged) किया जाता है।
2. एक नया वर्ज़न न्यूनतम-वर्ज़न फ़ेंस को आगे बढ़ाता है और कैश्ड मान को हटा देता है।
3. एक असफल कैश कमांड का पुनः प्रयास किया जाता है; समाप्त कार्य एक दृश्यमान क्वारंटाइन कतार में प्रवेश करता है।
4. एक समाधान (reconciliation) कार्य डेटाबेस वर्ज़न, आउटबॉक्स प्रगति और नमूना कैश्ड वर्ज़न की तुलना करता है।

एट-लीस्ट-वन्स डिलीवरी डिलीशन के साथ अच्छी तरह से काम करती है क्योंकि डुप्लिकेट DEL का कोई अतिरिक्त व्यावसायिक अर्थ नहीं होता है। यह दावा न करें कि पुनः प्रयास एक्ज़ैक्टली-वन्स निष्पादन बनाते हैं। एक उपभोक्ता Redis में डिलीट कर सकता है, संदेश को स्वीकार करने से पहले क्रैश हो सकता है, और फिर से डिलीट कर सकता है। सुरक्षित दोहराव और पता लगाने योग्य कमियां उपयोगी गुण हैं।

डेटाबेस कमिट से सफल इनवैलिडेशन तक के अंतराल को देखें, न कि केवल ब्रोकर कतार की आयु। उपयोगी मेट्रिक्स में invalidation_lag_seconds, इनवैलिडेशन विफलताएं और पुनः प्रयास, सबसे पुरानी क्वारंटाइन आयु, कैश-टू-सोर्स वर्ज़न लैग, ओवर-बजट कैश बायपास, डेटाबेस फ़िल QPS, और सिंगलफ़्लाइट के माध्यम से साझा किए गए समान-की कॉल्स की संख्या शामिल हैं।

चरण 5: टीटीएल और गेट के साथ 5-सेकंड की सीमा साबित करें

एक विश्वसनीय इवेंट अंततः आ जाता है, लेकिन "अंततः" की कोई समय इकाई नहीं होती है। कमिट से अधिकतम 5 सेकंड पुराने अनुबंध को एक स्वतंत्र सीमित-समय सुरक्षा की आवश्यकता होती है:

• घड़ियों, शेड्यूलिंग और डिटेक्शन के लिए मार्जिन आरक्षित करने के बाद भौतिक कैश टीटीएल को 5 सेकंड से कम सेट करें, और आधिकारिक वर्ज़न के कमिट समय से स्टेल एज की गणना करें।
• वैकल्पिक रूप से, जैसे ही इनवैलिडेशन लैग बजट के करीब पहुंचता है, विश्व स्तर पर या प्रभावित पार्टीशन द्वारा कैश पर भरोसा करना बंद करें और फ्रेशनेस आवश्यकता को पूरा करने वाला सोर्स पढ़ें।
• यदि दोनों संभव नहीं हैं, तो अनुबंध अंतिम कंसिस्टेंसी (eventual consistency) है और इसे 5-सेकंड की सीमा का दावा जारी नहीं रखना चाहिए।

टीटीएल एक बाउंड्री बैकस्टॉप है, प्राथमिक इनवैलिडेशन तंत्र नहीं। जिटर जोड़ें ताकि 2,000 कीज़ एक साथ समाप्त न हों, और प्रत्येक की के लिए मिसेस को कोएलेस करें। यदि सभी 2,000 एक्टिव कीज़ को प्रति 5-सेकंड अंतराल में कम से कम एक बार पढ़ा जाता है, तो समान रूप से वितरित समाप्ति औसतन प्रति सेकंड लगभग 400 फ़िल्स उत्पन्न करती है। वह अनुमान क्षमता की गारंटी नहीं है। लोकप्रियता विषमता (popularity skew), बैच समाप्ति, Redis विफलता और धीमी क्वेरीज़ शिखर उत्पन्न कर सकती हैं, इसलिए सुरक्षित डेटाबेस QPS और समवर्ती बल्कहेड्स के खिलाफ परीक्षण करें।

यदि 5-सेकंड का टीटीएल डेटाबेस क्षमता से अधिक है, तो तीन ईमानदार विकल्प हैं: सुरक्षित फ़िल क्षमता जोड़ें, इस अनुबंध की आवश्यकता वाले एक्टिव डेटा को कम करें, या पुराने बजट को शिथिल करें। चुपचाप टीटीएल बढ़ाना प्रॉम्प्ट का उल्लंघन करता है।

चरण 6: रेप्लिक लैग और रीड-योर-राइट्स को संभालें

सही डिलीशन के बाद भी, एक लैगिंग रेप्लिक एक पुराने वर्ज़न को फिर से भर सकता है। एक कठिन 5-सेकंड अनुबंध वाले मिस के लिए, वरीयता के इस क्रम का उपयोग करें:

1. इनवैलिडेशन के बाद पहले फ़िल के लिए प्राइमरी को पढ़ें।
2. रेप्लिक का उपयोग केवल तभी करें जब एक अवलोकनीय रीप्ले स्थिति आवश्यक कमिट स्थिति तक पहुंच गई हो।
3. एक राइट से source_version लौटाएं और बाद के रीड्स को min_version ले जाने दें; जब कैश या रेप्लिक पीछे हो तो प्राइमरी पर रूट करें।
4. जब रेप्लिक या इनवैलिडेशन लैग बजट से अधिक हो जाए तो एक फ्रेशनेस सर्किट ब्रेकर खोलें, और अयोग्य कैश्ड मान लौटाना बंद करें।

5-सेकंड का टीटीएल 5-सेकंड के डेटा की आयु को साबित नहीं करता है यदि फ़िल किसी ऐसे रेप्लिक से आया है जो पहले से ही 4 सेकंड पीछे है। पुरानी आयु सोर्स-ऑफ़-ट्रुथ कमिट से शुरू होती है, इसलिए रेप्लिक, इवेंट-चैनल और कैश देरी सभी की गणना होती है।

चरण 7: विकल्पों और उनकी सीमाओं की तुलना करें

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

पहले डिलीट करें, फिर डेटाबेस अपडेट करें। यह सरल है लेकिन डेटाबेस कमिट से पहले एक रीडर को पुराने डेटा को फिर से भरने की अनुमति देता है। एक विलंबित दूसरा डिलीट (delayed second delete) किसी विशेष समय की संभावना को कम करता है, लेकिन एक निश्चित विलंब असीमित रेप्लिक लैग, प्रोसेस रुकावटों या नेटवर्क दोषों को कवर नहीं कर सकता है। दूसरा डिलीट होने से पहले प्रोसेस भी क्रैश हो सकता है। यह एक सहायक उपाय हो सकता है, लेकिन यह अपने आप में बाउंडेड स्टेलनेस साबित नहीं करता है।

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

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

चरण 8: इनवेरिएंट्स और विफलता पाथ्स का परीक्षण करें

अपडेट के बाद किसी पेज को मैन्युअल रूप से रीफ़्रेश करने से कहीं अधिक करें। लेट स्टेल फ़िल को पुनरुत्पादित करने के लिए बैरियर का उपयोग करें। वर्ज़न 41 प्राप्त करने के बाद रीडर को रोकें। राइटर को वर्ज़न 42 कमिट करने दें, फ़ेंस को आगे बढ़ाने दें और मान को हटाने दें। पुराने रीडर को छोड़ें और दावा करें कि इसका सशर्त फ़िल विफल हो गया है। फिर इन मामलों का परीक्षण करें:

• PostgreSQL कमिट के तुरंत बाद राइटर को समाप्त करें और सत्यापित करें कि आउटबॉक्स अंततः इनवैलिडेट करता है;
• एक इनवैलिडेशन इवेंट को डुप्लिकेट और रीऑर्डर करें और सत्यापित करें कि उच्चतम वर्ज़न कभी पीछे नहीं जाता है;
• Redis डिलीट को विफल करें और पुनः प्रयास, क्वारंटाइन और टीटीएल बैकस्टॉप को सत्यापित करें;
• रेप्लिक रीप्ले को रोकें और सत्यापित करें कि फ़िल्स प्राइमरी का उपयोग करते हैं या किसी अयोग्य परिणाम को अस्वीकार करते हैं;
• इनवैलिडेशन की खपत को उसके गेट से आगे विलंबित करें और सत्यापित करें कि रीड्स कैश को बायपास करते हैं;
• 2,000 कीज़ को एक साथ समाप्ति के करीब लाएं और जिटर, सिंगलफ़्लाइट और डेटाबेस बल्कहेड्स को सत्यापित करें;
• Redis को अनुपलब्ध बनाएं और आधिकारिक निर्णयों द्वारा अपने आवश्यक पाथ को बनाए रखते हुए डिस्प्ले रीड्स के लिए बजटीय गिरावट को सत्यापित करें।

मुख्य इनवेरिएंट्स हैं: लौटाया गया कैश वर्ज़न कभी भी कॉलर के min_version से कम नहीं होता है; एक इनवैलिडेटेड फ़िल जनरेशन लिख नहीं सकती है; एक आधिकारिक व्यावसायिक कार्रवाई कभी भी डिस्प्ले कैश पर भरोसा नहीं करती है; पुरानी आयु 5 सेकंड से अधिक नहीं होती है; और डेटाबेस फ़िल्स परीक्षण किए गए सुरक्षित QPS और समवर्तीता के भीतर रहते हैं।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं यह वादा करके शुरुआत नहीं करूंगा कि PostgreSQL और Redis हर पल मेल खाते हैं। मैं रीड अनुबंधों को विभाजित करूंगा। प्रोडक्ट के नाम और चित्र PostgreSQL कमिट से अधिकतम 5 सेकंड के लिए पुराने हो सकते हैं। इन्वेंट्री कटौती, अनुमतियां, बैलेंस और चेकआउट निर्णय आधिकारिक स्थिति का उपयोग करना जारी रखते हैं। जब किसी राइटर को रीड-योर-राइट्स की आवश्यकता होती है, तो राइट API सोर्स वर्ज़न लौटाता है। बाद का रीड उस न्यूनतम वर्ज़न की आपूर्ति करता है और Redis के पुराने होने पर प्राइमरी का उपयोग करता है।

आधार पैटर्न कैश-असाइड है। एक रीड केवल तभी हिट लौटाता है जब उसकी आयु और वर्ज़न योग्य हों। एक मिस product_id द्वारा सिंगलफ़्लाइट का उपयोग करता है, एक मोनोटोनिक रूप से वर्ज़न वाली पंक्ति प्राप्त करता है, और एक सशर्त फ़िल करता है। एक PostgreSQL ट्रांज़ैक्शन प्रोडक्ट को अपडेट करता है, उसके वर्ज़न को बढ़ाता है, और एक आउटबॉक्स पंक्ति सम्मिलित करता है। कमिट के बाद, एप्लिकेशन तुरंत Redis को हटाने का प्रयास करता है। एक रिले या CDC उपभोक्ता ड्यूरेबल इवेंट से पुनः प्रयास करता है, इसलिए कमिट के बाद क्रैश होने पर इनवैलिडेशन का दायित्व स्थायी रूप से नहीं खोता है।

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

आउटबॉक्स रिकवरेबल अंतिम इनवैलिडेशन साबित करता है, न कि 5-सेकंड की समय सीमा। मैं परिचालन मार्जिन के साथ बजट के भीतर एक हार्ड टीटीएल सेट करता हूं, और कमिट-टू-इनवैलिडेशन लैग को मापता हूं। जैसे ही वह लैग बजट के करीब पहुंचता है, रीड्स Redis को बायपास करते हैं। यदि सभी 2,000 एक्टिव कीज़ को हर 5 सेकंड में एक्सेस किया जाता है, तो एक समान फ़िल्स औसतन लगभग 400 प्रति सेकंड होती हैं, इसलिए मैं टीटीएल जिटर, प्रति-की अनुरोध कोएलेसिंग और एक डेटाबेस समवर्ती बल्कहेड का भी उपयोग करता हूं।

सत्यापन के लिए, मैं थ्रेड ऑर्डरिंग को नियंत्रित करता हूं और कमिट-देन-क्रैश, लेट-रीडर, डुप्लिकेट और रीऑर्डर्ड इवेंट, असफल Redis डिलीट और रेप्लिक-लैग दोषों को इंजेक्ट करता हूं। स्वीकृति का अर्थ है कि एक पुरानी जनरेशन फ़िल नहीं कर सकती है, सोर्स वर्ज़न पीछे नहीं जाते हैं, पुरानी आयु 5 सेकंड के भीतर रहती है, आधिकारिक कार्रवाइयां डिस्प्ले कैश को बायपास करती हैं, और डेटाबेस लोड मापे गए बजट के भीतर रहता है।"

सामान्य गलतियां

• "डेटाबेस और कैश के बीच मजबूत कंसिस्टेंसी" का दावा करना → उत्तर वैध रीड्स, विफलता की समय सीमा, या दोनों प्रणालियों में एक ट्रांज़ैक्शन सीमा को परिभाषित नहीं करता है → बाउंडेड स्टेलनेस, रीड-योर-राइट्स और आधिकारिक रीड्स के लिए अलग-अलग अनुबंध बताएं।
• डेटाबेस को अपडेट करने से पहले कैश को हटाना → उन ऑपरेशनों के बीच एक मिस पुराने डेटाबेस मान को पढ़ता है और पुनर्स्थापित करता है → पहले डेटाबेस को कमिट करें, फिर इनवैलिडेट करें, ड्यूरेबल मरम्मत के साथ।
• कमिट के बाद केवल इन-मेमोरी संदेश प्रकाशित करना → प्रकाशन से पहले एक क्रैश इनवैलिडेशन को स्थायी रूप से खो देता है → एक ही ट्रांज़ैक्शन में एक आउटबॉक्स लिखें या डेटाबेस-लॉग परिवर्तनों को कैप्चर करें।
• यह मान लेना कि DEL हर रेस को समाप्त करता है → एक पुराना रीड डिलीट होने के बाद अपना सेट पूरा कर सकता है → एक फ़िल लीज या एक वर्ज़न फ़ेंस के साथ पुराने मानों को अस्वीकार करें जो मान डिलीट होने के बाद भी जीवित रहता है।
• वर्ज़न को केवल कैश मान के अंदर रखना → एक खाली कैश में तुलना करने के लिए कोई नया वर्ज़न नहीं होता है और वह पुराने मान को स्वीकार कर सकता है → न्यूनतम वर्ज़न या जनरेशन को एक अलग फ़ेंस में रखें और फ़िल को एटॉमिक रूप से जांचें।
• डुप्लिकेट खपत को एक त्रुटि मानना → पावती (acknowledgement) से पहले एक उपभोक्ता क्रैश स्वाभाविक रूप से पुनः डिलीवरी बनाता है → एट-लीस्ट-वन्स डिलीवरी के तहत डिलीशन और उच्चतम-वर्ज़न प्रगति को इडेम्पोटेंट बनाएं।
• 5 सेकंड का वादा करने के लिए आउटबॉक्स का उपयोग करना → पुनः प्रयास करने की क्षमता अंतिम हैंडलिंग साबित करती है, एक सीमित विलंब नहीं → एक हार्ड टीटीएल या एक ओवर-बजट बायपास गेट जोड़ें और एंड-टू-एंड कमिट-टू-इनवैलिडेशन लैग को मापें।
• किसी भी रीड रेप्लिक से फ़िल करना → रेप्लिक लैग सही इनवैलिडेशन के बाद पुराने डेटा को फिर से भर सकता है → रीप्ले स्थिति की जांच करें, प्राइमरी का उपयोग करें, या न्यूनतम सोर्स वर्ज़न की आवश्यकता रखें।
• एक डिस्प्ले स्नैपशॉट में सभी फ़ील्ड्स को कैश करना → डिस्प्ले-डेटा स्टेल भत्ता इन्वेंट्री, अनुमतियों और चेकआउट में लीक हो जाता है → डेटा अनुबंधों को विभाजित करें और अपरिवर्तनीय क्रियाओं के लिए आधिकारिक स्थिति को दोबारा पढ़ें।
• Redis विफल होने पर सभी ट्रैफ़िक को डेटाबेस पर भेजना → 20,000 रीड्स प्रति सेकंड सोर्स ऑफ़ ट्रुथ को प्रभावित कर सकते हैं → बल्कहेड्स, दर सीमाओं, स्पष्ट गिरावट और नियंत्रित पुनर्प्राप्ति के साथ इसे सुरक्षित रखें।
• एक निश्चित विलंबित डबल डिलीट (delayed double delete) का उपयोग करना → स्लीप (sleep) असीमित लैग को कवर नहीं कर सकता है और दूसरा डिलीट भी खो सकता है → ड्यूरेबल इनवैलिडेशन, एक फ़ेंस और एक सीमित-समय बैकस्टॉप को बनाए रखते हुए इसे एक संभावना अनुकूलन के रूप में मानें।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: क्या होगा यदि प्रोडक्ट की कीमतों के लिए भी रीड-योर-राइट्स की आवश्यकता हो?

राइट API से कमिट किया गया source_version लौटाएं। उस सत्र में बाद का रीड min_version भेजता है; यदि Redis पुराना है, तो प्राइमरी को पढ़ें और सशर्त रूप से केवल नए वर्ज़न को कैश करें। यदि राइटर को केवल परिणाम प्रदर्शित करने की आवश्यकता है, तो कमिट की गई पंक्ति को सीधे लौटाएं और संक्षेप में कैश को बायपास करें। चेकआउट को अभी भी आधिकारिक ट्रांज़ैक्शन में कीमत को फिर से मान्य करना होगा; रीड-योर-राइट्स भुगतान प्राधिकरण नहीं है।

फॉलो-अप 2: वर्ज़न फ़ेंस केवल कैश्ड मान में ही क्यों नहीं रह सकता है?

इनवैलिडेशन उस मान को हटा देता है, इसलिए एक सामान्य तुलना अब वर्ज़न 42 को नहीं देख सकती है। एक अनुरोध जिसने पहले वर्ज़न 41 पढ़ा था, वह 41 को एक खाली की के लिए एक वैध मान मान सकता है। एक अलग फ़ेंस या मिस लीज मान डिलीट होने के बाद भी जीवित रहता है और रिकॉर्ड करता है कि या तो वर्ज़न 42 मौजूद है या पुरानी फ़िल अनुमति रद्द कर दी गई है।

फॉलो-अप 3: क्या कोई ट्रांज़ैक्शनल आउटबॉक्स डुप्लिकेट भेज सकता है?

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

फॉलो-अप 4: यदि CDC इनवैलिडेशन को संभालता है तो क्या टीटीएल 30 मिनट हो सकता है?

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

फॉलो-अप 5: रेप्लिक लैग सामान्य रूप से केवल दसियों मिलीसेकंड का होता है। प्राइमरी का उपयोग क्यों करें?

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

फॉलो-अप 6: एक डिस्ट्रिब्यूटेड लॉक रखते हुए PostgreSQL और Redis को अपडेट क्यों नहीं करते?

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

फॉलो-अप 7: जब Redis पूरी तरह से अनुपलब्ध हो तो आप 5-सेकंड की सीमा कैसे बनाए रखते हैं?

डिस्प्ले रीड्स Redis को बायपास करते हैं, लेकिन प्रत्येक सोर्स रीड डेटाबेस बल्कहेड्स और दर सीमाओं से होकर गुजरता है। यदि क्षमता अपर्याप्त है, तो एक स्पष्ट डिग्रेडेड परिणाम या विफलता लौटाएं। एक प्रोसेस-लोकल पुरानी प्रतिलिपि 5-सेकंड के बजट के भीतर रहते हुए संक्षेप में सेवा कर सकती है; उसके बाद इसे अयोग्य घोषित कर दिया जाता है। इनवैलिडेशन को खाली करते हुए दर-सीमित वार्मिंग के साथ पुनर्प्राप्त करें ताकि एक कोल्ड कैश डेटाबेस को फिर से प्रभावित न करे।

फॉलो-अप 8: आप कैसे साबित करते हैं कि प्रोडक्शन में लंबे समय तक रहने वाले पुराने मान नहीं हैं?

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