हॉट की (Hot Key) के एक्सपायर होने पर आप कैश स्टैम्पीड (Cache Stampede) को कैसे रोकते हैं?

प्रॉम्प्ट और स्कोप

एक हॉट प्रोडक्ट-कॉन्फ़िगरेशन की पर प्रति सेकंड 50,000 रीड्स आते हैं। सोर्स डेटाबेस प्रति सेकंड 200 क्वेरीज़ तक सुरक्षित है, और कैश को दोबारा बनाने में p95 पर 800 ms लगते हैं। कैश्ड डेटा 10 मिनट के लिए फ्रेश रहता है, और व्यवसाय अधिकतम 30 सेकंड के पुरानेपन को सहन कर सकता है। यह सर्विस 100 स्टेटलेस एप्लिकेशन इंस्टेंसेस पर चलती है जो एक रिमोट कैश और समान सोर्स डेटाबेस साझा करते हैं।

संपूर्ण रीड और रिफ्रेश पाथ डिज़ाइन करें। इसमें सॉफ्ट एक्सपायरी, हार्ड एक्सपायरी, पहला कोल्ड लोड, रिफ्रेशर क्रैश, कैश आउटेज और रिफ्रेश के दौरान सोर्स डेटा में बदलाव को शामिल करें। समझाएं कि आप यह कैसे साबित करेंगे कि यह डिज़ाइन केवल समवर्ती (concurrent) लोड को डेटाबेस पर स्थानांतरित नहीं करता है। थ्रूपुट, लेटेंसी और एक्सपायरी मान साक्षात्कार के इनपुट हैं, किसी उत्पाद के बारे में प्रदर्शन के दावे नहीं।

यह बैकएंड विश्वसनीयता (reliability) से जुड़ा प्रश्न है। 2026 SRE साक्षात्कार प्रश्नों का एक वर्तमान सार्वजनिक सेट स्पष्ट रूप से प्रति सेकंड 100,000 अनुरोधों के तहत एक महत्वपूर्ण की (key) के एक्सपायर होने से होने वाले कैश स्टैम्पीड को प्रस्तुत करता है; यह संस्करण उस परिदृश्य को मापने योग्य इंजीनियरिंग बाधाओं में बदल देता है। यह इन-प्रोसेस LRU निष्कासन नीति (eviction policy) को लागू करने से अलग है क्योंकि इसकी मुख्य समस्या क्रॉस-इंस्टेंस समवर्तीता और विफलता सिमेंटिक्स है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

पहला, उम्मीदवार को एक्सपायरी घटना को परिमाणित (quantify) करना चाहिए। यदि 800 ms के रीबिल्ड के दौरान प्रत्येक आगमन कैश को बायपास करता है, तो लगभग 50,000 × 0.8 = 40,000 अनुरोध ओरिजिन तक पहुँचने का प्रयास कर सकते हैं। यह प्रति सेकंड 200 क्वेरीज़ की सुरक्षित दर से बहुत अधिक है। कैश प्रविष्टि गायब होने पर केवल कैश जोड़ने से सिंक्रनाइज़्ड लोड की समस्या हल नहीं हुई है।

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

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

अंत में, साक्षात्कारकर्ता को यह सुनना चाहिए कि डिज़ाइन किसी पुराने रिफ्रेशर को नए मान को ओवरराइट करने से कैसे रोकता है। लीज केवल अपनी वैधता विंडो के दौरान विशिष्टता (exclusion) प्रदान करती है; यह एग्जैक्ट्ली-वन्स (exactly-once) की गारंटी नहीं है। कैश प्रविष्टियों को एक सोर्स वर्ज़न या जनरेशन की आवश्यकता होती है, और डेटा को बदलने से पहले राइट्स को वर्ज़न्स की तुलना करनी चाहिए।

स्पष्ट करने हेतु प्रश्न

• क्या पुराना डेटा वास्तव में सुरक्षित है? यह परिदृश्य अधिकतम 30 सेकंड की अनुमति देता है। बैलेंस, ऑथराइजेशन और इन्वेंट्री कटौती के लिए सख्त व्यवहार की आवश्यकता हो सकती है।
• ओरिजिन लिमिट क्या मापती है? प्रति सेकंड 200 क्वेरीज़ को डेटाबेस-स्तरीय सुरक्षित सीमा मानें, साथ ही प्रति-की समवर्तीता और टाइमआउट सीमाओं के बारे में भी पूछें।
• क्या कोल्ड लोड एक डिफ़ॉल्ट मान लौटा सकता है? डिफ़ॉल्ट रूप से कोई पुराना मान मौजूद नहीं होता है, इसलिए केवल एक रिफ्रेशर ओरिजिन तक पहुँचता है और फॉलोअर्स सीमित समय तक प्रतीक्षा करते हैं। यदि उपलब्ध हो तो स्टैटिक डिफ़ॉल्ट एक स्पष्ट उत्पाद डिग्रेडेशन है।
• प्रविष्टियों को कैसे इनवैलिडेट किया जाता है? प्रत्येक कॉपी को एक ही सेकंड में भौतिक रूप से हटाने के बजाय लॉजिकल फ्रेशनेस और हार्ड-एक्सपायरी टाइमस्टैम्प का उपयोग करें। सोर्स चेंज इवेंट्स प्रविष्टियों को जल्दी रिफ्रेश या इनवैलिडेट कर सकते हैं।
• क्या यह मल्टी-रीजन है? एक रीजन में 100 इंस्टेंसेस से शुरुआत करें। एकाधिक रीजन्स के लिए आवंटित ओरिजिन बजट की आवश्यकता होती है; यह नहीं माना जाना चाहिए कि क्रॉस-रीजन लॉक हर विफलता मोड को हल कर देगा।
• क्या कॉल करने वालों को पता होना चाहिए कि डेटा पुराना है? आंतरिक प्रतिक्रियाओं और टेलीमेट्री में कम से कम stale_age और डिग्रेडेशन का कारण रिकॉर्ड होना चाहिए। उत्पाद की आवश्यकताएं तय करती हैं कि अंतिम उपयोगकर्ता इसे देखते हैं या नहीं।
• यदि कैश विफल हो जाए तो क्या होगा? डिग्रेडेशन और ओरिजिन बजट पहले से परिभाषित करें। कैश त्रुटि का अर्थ यह नहीं हो सकता कि प्रत्येक अनुरोध डेटाबेस से क्वेरी करे।

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

“मैं मान के साथ fresh_until, stale_until और सोर्स वर्ज़न को कैश करूँगा। फ्रेश हिट्स सीधे लौटते हैं। 30-सेकंड की स्टेल विंडो के दौरान, पुराना मान लौटाएं और प्रति-प्रोसेस singleflight तथा ओनरशिप टोकन और TTL के साथ एक डिस्ट्रीब्यूटेड लीज का उपयोग करके एक रिफ्रेशर चुनें। कोल्ड या हार्ड मिस पर, फॉलोअर्स केवल एक सीमित समय तक प्रतीक्षा करते हैं और जिटर (jitter) के साथ पुनः पढ़ते हैं। रिफ्रेश राइट्स सोर्स वर्ज़न्स की तुलना करते हैं, और लीज रिलीज़ टोकन की जांच करती है। चूंकि लीज एक्सपायरी अभी भी ओवरलैप की अनुमति दे सकती है, इसलिए डेटाबेस को प्रति-की और ग्लोबल बल्कहेड की भी आवश्यकता होती है। मैं एक्सपायरी लोड टेस्ट, रिफ्रेशर क्रैश, लीज ओवररन और कैश-आउटेज ड्रिल्स के साथ ओरिजिन QPS, समवर्तीता और अधिकतम स्टेल एज को सत्यापित करूँगा।”

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

केवल व्यावसायिक मान संग्रहीत करने के बजाय एक कैश प्रविष्टि को परिभाषित करके शुरुआत करें:

CacheEntry {
  value
  source_version
  generated_at
  fresh_until
  stale_until
}

fresh_until 10 मिनट की फ्रेशनेस अवधि को समाप्त करता है, और stale_until इसे 30 सेकंड से अधिक नहीं बढ़ाता है। रिमोट की (key) का भौतिक TTL stale_until के साथ एक छोटे क्लीनअप मार्जिन को कवर करना चाहिए; अन्यथा कैश उस मान को हटा देगा जो सॉफ्ट एक्सपायरी के दौरान सर्व करने के लिए अभी भी सुरक्षित है। स्टेल विंडो एक व्यावसायिक बजट है और बार-बार रिफ्रेश विफलताओं के बाद इसे चुपचाप नहीं बढ़ाया जाना चाहिए।

रीड पाथ को स्यूडोकोड के रूप में व्यक्त किया जा सकता है:

entry = cache.get(key)
now = clock.now()

if entry exists and now < entry.fresh_until:
  return entry.value

if entry exists and now < entry.stale_until:
  try_refresh_async(key)
  return entry.value

return rebuild_or_wait(key, request_deadline)

सॉफ्ट-एक्सपायरी पाथ अनुरोध लेटेंसी की सुरक्षा करता है। पहला अनुरोध जो सॉफ्ट एक्सपायरी को नोटिस करता है वह बैकग्राउंड रिफ्रेश का प्रयास करता है जबकि अन्य पुराने मान का उपयोग करना जारी रखते हैं। प्रति-प्रोसेस singleflight की (key) के आधार पर रिफ्रेश कॉल्स को संयोजित करता है; सार्वजनिक Go कार्यान्वयन इसे प्रति की (key) एक इन-फ्लाइट निष्पादन के रूप में परिभाषित करता है जिसका परिणाम डुप्लिकेट कॉलर्स के साथ साझा किया जाता है। यह प्रोसेस सीमाओं को पार नहीं करता है, इसलिए यह 100 इंस्टेंसेस पर अकेले पर्याप्त नहीं है।

क्रॉस-इंस्टेंस रिफ्रेश के लिए समय-सीमित लीज का उपयोग करें। एक दावेदार (contender) एक रैंडम, गैर-पुन: प्रयोज्य token बनाता है और निष्पादित करता है:

SET refresh:{key} {token} NX PX {lease_ms}

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

lease_ms को मापे गए रिफ्रेश p99 प्लस नेटवर्क और शेड्यूलिंग मार्जिन से ऊपर सेट करें, यांत्रिक रूप से 800 ms p95 पर नहीं। एक लीज जो बहुत छोटी है वह ओवरलैप बढ़ाती है; जो बहुत लंबी है वह क्रैश के बाद टेकओवर में देरी करती है। लीज एक्सपायरी केवल एक नए दावेदार को प्रयास करने की अनुमति देती है; यह साबित नहीं करती कि पुराना ऑपरेशन बंद हो गया है। इसलिए ओरिजिन रीड्स को अभी भी एक प्रति-की singleflight सर्विस या डेटाबेस बल्कहेड की आवश्यकता होती है, और कैश राइट्स को ओवरलैपिंग निष्पादनों को सहन करना चाहिए।

डेटा के साथ एक मोनोटोनिक सोर्स वर्ज़न पढ़ें, जैसे कि एक रो वर्ज़न या इवेंट सीक्वेंस। कैश को केवल तभी बदलें जब new.source_version >= cached.source_version हो। यदि सोर्स के पास कोई विश्वसनीय वर्ज़न नहीं है, तो साझा समन्वय स्टोरेज में एक एटॉमिक इंक्रीमेंट के साथ रिफ्रेश जनरेशन्स आवंटित करें और कैश पर उनकी एटॉमिक रूप से तुलना करें। कैश अभी भी सत्य का स्रोत (source of truth) नहीं है; किसी चेंज इवेंट द्वारा पहले से इंस्टॉल किए गए नए वर्ज़न को विलंबित रिफ्रेश द्वारा ओवरराइट नहीं किया जाना चाहिए।

हार्ड एक्सपायरी या पहले लोड में कोई स्वीकार्य पुराना मान नहीं होता है। लीज ओनर ओरिजिन बल्कहेड में प्रवेश करने के बाद ही रीबिल्ड करता है। फॉलोअर्स एक साथ पोलिंग करने के बजाय अनुरोध की समय सीमा के भीतर छोटे, जिटर वाले अंतरालों पर कैश को फिर से पढ़ते हैं। जब वह प्रतीक्षा समाप्त हो जाती है, तो एक स्पष्ट डिग्रेडेड प्रतिक्रिया या त्रुटि लौटाएं। यदि उत्पाद अनुमति देता है तो एक स्टैटिक डिफ़ॉल्ट का उपयोग किया जा सकता है, लेकिन स्पष्ट उपलब्धता के चक्कर में सभी 50,000 अनुरोधों को ओरिजिन पर नहीं भेजा जाना चाहिए।

ओरिजिन की अंतिम रक्षा पंक्ति में प्रति-की समवर्तीता कैप, एक ग्लोबल रिफ्रेश समवर्तीता कैप और एक क्वेरी-रेट बजट शामिल होना चाहिए। सामान्य परिस्थितियों में एक की (key) के लिए केवल एक रीबिल्ड चलता है। लीज विफलताओं के दौरान, बल्कहेड अभी भी कुल ओरिजिन कार्य को एक सुरक्षित सीमा के भीतर रखता है। जब क्षमता समाप्त हो जाती है, तो रिफ्रेश तेजी से विफल हो जाते हैं या एक सीमित कतार में प्रवेश करते हैं; सॉफ्ट-एक्सपायर्ड अनुरोध 30 सेकंड से कम पुराने मानों का उपयोग करना जारी रखते हैं, जबकि हार्ड मिस परिभाषित डिग्रेडेशन नीति का पालन करते हैं।

जब कैश अनुपलब्ध हो, तो अनुप्रयोगों को संपूर्ण रीड रेट को डेटाबेस पर स्थानांतरित नहीं करना चाहिए। एक अल्पकालिक केवल-पढ़ने योग्य नियर-कैश (near-cache) स्वीकार्य पुराने मान प्रदान कर सकता है, लेकिन सभी आवश्यक ओरिजिन रीड्स अभी भी ग्लोबल बल्कहेड से होकर गुजरते हैं। नियर-कैश मान के बिना अनुरोधों को डिग्रेड या विफल होना चाहिए। रिकवरी के दौरान एक नियंत्रित दर पर हॉट कीज़ को वार्म करें, बजाय इसके कि प्रत्येक इंस्टेंस एक साथ रीफिल करने लगे। रैंडम TTL जिटर तब मदद करता है जब कई अलग-अलग कीज़ एक साथ एक्सपायर होती हैं, लेकिन यह एक हॉट की के समवर्ती पुनर्निर्माण को हल नहीं करता है।

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

पूर्वानुमेय हॉट डेटा को fresh_until से पहले रिफ्रेश किया जा सकता है। Cloudflare का प्रकाशित प्रोबेबिलिस्टिक अर्ली-रीवैलिडेशन दृष्टिकोण एक्सपायरी करीब आने पर रिफ्रेश की संभावना को बढ़ाता है, जिससे उच्च अनुरोध दरों के तहत लॉक विवाद कम होता है। "1% अनुरोधों को रिफ्रेश करें" जैसा एक निश्चित नियम असुरक्षित है क्योंकि इसका व्यवहार ट्रैफ़िक के साथ बदलता है। सीमित स्टेल विंडो और बैकग्राउंड रिफ्रेश भी HTTP stale-while-revalidate के सिमेंटिक्स से मेल खाते हैं: पुराना कंटेंट केवल एक स्पष्ट अंतराल के भीतर अनुमत है जबकि रीवैलिडेशन एसिंक्रोनस रूप से होता है।

मल्टीपल रीजन्स के लिए, आवंटित ओरिजिन QPS और समवर्तीता बजट के साथ रीजनल कैश और रीजनल रिफ्रेशर्स को प्राथमिकता दें। एक एकल ग्लोबल लीज रीड पाथ में क्रॉस-रीजन लेटेंसी और विभाजन व्यवहार जोड़ती है। यदि प्रत्येक रीजन एक ओरिजिन साझा करता है, तो एक कंट्रोल प्लेन रिफ्रेश बजट आवंटित कर सकता है या ओरिजिन एक केंद्रीकृत रीबिल्ड सर्विस को प्रदर्शित कर सकता है। किसी भी मामले में, रीजनल बजटों का योग प्रति सेकंड 200 क्वेरीज़ के भीतर रहना चाहिए।

फ्रेश-हिट, स्टेल-सर्व्ड और हार्ड-मिस दरों; स्टेल एज; रिफ्रेश प्रयासों और विफलताओं; singleflight शेयर्ड कॉलर्स; लीज विवाद और एक्सपायरी; रिफ्रेश लेटेंसी; ओरिजिन QPS, समवर्तीता और रिजेक्शन; तथा कैश लेटेंसी और त्रुटियों का निरीक्षण करें। केवल कैश हिट रेट पर निर्भर रहने के बजाय समाप्त हो चुके ओरिजिन बजट, stale_until के करीब पहुँच रहे मानों और निरंतर रिफ्रेश विफलता पर अलर्ट सेट करें।

सीधे इनवेरिएंट्स का परीक्षण करें। प्रति सेकंड 50,000 अनुरोधों के तहत की (key) को एक्सपायर करें और सामान्य मामले में प्रति की (key) एक ओरिजिन रीबिल्ड सुनिश्चित करें। इसके राइट से पहले रिफ्रेश को क्रैश करें और सत्यापित करें कि पुराना डेटा उपलब्ध रहता है और लीज एक्सपायरी के बाद एक उत्तराधिकारी पदभार संभालता है। एक पुराने रिफ्रेशर को लीज से अधिक समय तक रोकें और सत्यापित करें कि यह एक नए वर्ज़न को प्रतिस्थापित नहीं कर सकता है। कैश को अक्षम करें और सत्यापित करें कि ओरिजिन प्रति सेकंड 200 क्वेरीज़ और इसके समवर्तीता बल्कहेड के भीतर रहता है। कई कीज़ को एक साथ एक्सपायर करें और TTL जिटर प्लस ग्लोबल बजट को सत्यापित करें।

मजबूत नमूना उत्तर

“मैं सबसे खराब स्थिति वाले लोड से शुरुआत करूँगा। प्रति सेकंड पचास हजार अनुरोधों को 800 ms के रीबिल्ड से गुणा करने पर एक्सपायरी विंडो के दौरान लगभग 40,000 आगमन होते हैं, जबकि डेटाबेस केवल 200 क्वेरीज़ प्रति सेकंड के लिए सुरक्षित है। कोई भी फॉलोअर सीधे ओरिजिन पर नहीं जाना चाहिए।

मैं मान को उसके सोर्स वर्ज़न, fresh_until और stale_until के साथ कैश करूँगा। इसे 10 मिनट के लिए सीधे लौटाएं, फिर रिफ्रेश का प्रयास करते हुए इसे 30 अतिरिक्त सेकंड तक सर्व करें। प्रत्येक प्रोसेस पहले singleflight के साथ स्थानीय कार्य को संयोजित करता है, फिर दावेदार क्रॉस-इंस्टेंस रिफ्रेशर चुनने के लिए SET lock token NX PX lease का उपयोग करते हैं। ओनर डेटाबेस से क्वेरी करने से पहले कैश की फिर से जांच करता है। लीज रिलीज़ टोकन की तुलना करती है, और कैश राइट्स सोर्स वर्ज़न्स की तुलना करते हैं ताकि एक पुराना रिफ्रेशर एक नई लीज को हटा न सके या नए डेटा को ओवरराइट न कर सके।

कोल्ड लोड पर या 30 सेकंड के बाद, कोई स्वीकार्य पुराना मान नहीं होता है। एक अनुरोध रीबिल्ड करता है जबकि फॉलोअर्स अपनी समय सीमा तक जिटर के साथ पुनः पढ़ते हैं, फिर एक स्पष्ट डिफ़ॉल्ट डिग्रेडेशन का उपयोग करते हैं या एक त्रुटि लौटाते हैं। डेटाबेस में प्रति-की और ग्लोबल बल्कहेड भी हैं क्योंकि लीज एक्सपायरी ओवरलैपिंग रिफ्रेशर्स की अनुमति दे सकती है; एक लॉक क्षमता सुरक्षा का विकल्प नहीं है।

मैं सटीक एक्सपायरी सीमा पर लोड-टेस्ट करूँगा और एक रिफ्रेशर क्रैश, लीज से अधिक लंबा पॉज, कैश विफलता और एक समवर्ती सोर्स अपडेट इंजेक्ट करूँगा। स्वीकृति मानदंडों में 200 से अधिक ओरिजिन QPS न होना, प्रति की (key) एक सामान्य रीबिल्ड, 30 सेकंड से अधिक पुरानी स्टेल एज न होना, और विलंबित राइटर से कोई वर्ज़न रिग्रेशन न होना शामिल है। यह लेटेंसी, फ्रेशनेस और ओरिजिन सुरक्षा को मापने योग्य सीमाएं देता है।”

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

• केवल रैंडम TTL जिटर जोड़ना → यह अलग-अलग कीज़ में एक्सपायरी को फैलाता है लेकिन एक हॉट की के समवर्ती रीबिल्ड को नहीं रोकता है → प्रति की (key) कार्य को संयोजित करें और ओरिजिन बल्कहेड बनाए रखें।
• केवल इन-प्रोसेस singleflight का उपयोग करना → एक सौ इंस्टेंसेस अभी भी 100 रिफ्रेशर्स बना सकते हैं → लोकल कोएलेसिंग को क्रॉस-इंस्टेंस लीज के साथ संयोजित करें।
• रिफ्रेश अधिकार प्राप्त करने से पहले डेटाबेस को पढ़ना → कॉनक्रेन्सी स्पाइक पहले ही ओरिजिन तक पहुँच चुकी होती है → पहले चुनाव करें, कैश की पुनः जांच करें, और फिर ओरिजिन बजट में प्रवेश करें।
• बिना TTL के SETNX लॉक लेना → एक क्रैश हुआ रिफ्रेशर अपडेट को अनिश्चित काल के लिए ब्लॉक कर सकता है → टेकओवर व्यवहार के साथ एक सीमित लीज का उपयोग करें।
• एक साधारण DEL के साथ रिलीज़ करना → एक पुराना रिफ्रेशर अपने उत्तराधिकारी की लीज को हटा सकता है → एटॉमिक रूप से केवल तभी रिलीज़ करें जब अद्वितीय टोकन अभी भी मेल खाता हो।
• लीज को एग्जैक्ट्ली-वन्स निष्पादन मानना → TTL से अधिक समय तक रुका हुआ प्रोसेस किसी उत्तराधिकारी के साथ ओवरलैप हो सकता है → ओवरलैप को सहन करने के लिए ओरिजिन बल्कहेड और वर्ज़न वाले राइट्स का उपयोग करें।
• विफलताओं के बाद हमेशा के लिए पुराना डेटा सर्व करना → डेटा की आयु अपनी ऊपरी सीमा खो देती है → केवल stale_until से पहले सर्व करें, फिर स्पष्ट रूप से डिग्रेड करें या विफल हों।
• कैश आउटेज के दौरान सभी ट्रैफ़िक को ओरिजिन पर भेजना → 50,000 रीड्स प्रति सेकंड 200 के लिए सुरक्षित ओरिजिन को पूरी तरह से क्रैश कर देंगे → जहाँ अनुमति हो वहाँ नियर-कैश मानों का उपयोग करें और प्रत्येक ओरिजिन रीड को साझा बजट के माध्यम से रूट करें।
• स्टैम्पीड, एवलांच और पेनेट्रेशन को मिला देना → समाधान विफलता से मेल नहीं खाता → उनकी संबंधित समस्याओं के लिए रिक्वेस्ट कोएलेसिंग, TTL जिटर और नेगेटिव कैशिंग का उपयोग करें।
• केवल हिट रेट की निगरानी करना → एक उच्च हिट रेट विफल रिफ्रेश और संक्षिप्त ओरिजिन स्पाइक्स को छिपा सकती है → स्टेल एज, रिफ्रेश समवर्तीता, लीज और ओरिजिन बजट की भी निगरानी करें।

फॉलो-अप्स

फॉलो-अप 1: क्या होगा यदि व्यवसाय पुराना डेटा बिल्कुल भी सर्व नहीं कर सकता है?

पुराने उत्तरों को हटा दें और फॉलोअर्स को केवल एक सीमित अवधि तक प्रतीक्षा करने दें। पर्याप्त रीबिल्ड क्षमता प्रदान करें और ओरिजिन सुरक्षा का त्याग किए बिना स्पष्ट विफलताएं लौटाएं।

फॉलो-अप 2: लीज TTL कितनी लंबी होनी चाहिए?

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

फॉलो-अप 3: क्या होगा यदि रिफ्रेश के दौरान सोर्स डेटा बदल जाए?

एक सोर्स वर्ज़न पढ़ें और साथ रखें, फिर सशर्त रूप से कैश को अपडेट करें। किसी चेंज इवेंट द्वारा इंस्टॉल किए गए नए वर्ज़न को विलंबित रिफ्रेश द्वारा प्रतिस्थापित नहीं किया जाना चाहिए।

फॉलो-अप 4: यदि पूरा कैश क्लस्टर अनुपलब्ध हो तो क्या होगा?

स्वीकार्य नियर-कैश मान सर्व करें, प्रत्येक आवश्यक ओरिजिन रीड को ग्लोबल बल्कहेड के पीछे रखें, जब कोई कॉपी मौजूद न हो तो डिग्रेड करें, और रिकवरी के दौरान नियंत्रित दर पर कीज़ को वार्म करें।

फॉलो-अप 5: नेगेटिव कैशिंग इसमें कैसे फिट बैठती है?

पेनेट्रेशन को रोकने के लिए एक संक्षिप्त TTL के लिए एक पुष्ट "not found" परिणाम को कैश करें। यह मौजूदा हॉट की के लिए रिफ्रेश को संयोजित करने से स्वतंत्र है।

फॉलो-अप 6: प्रोबेबिलिस्टिक अर्ली रिफ्रेश कब उपयोगी होता है?

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

फॉलो-अप 7: क्या रीजन्स को एक लॉक साझा करना चाहिए?

आमतौर पर नहीं। क्षेत्रीय रूप से रिफ्रेश करें और ओरिजिन बजट आवंटित करें। केंद्रीय समन्वय केवल तभी उचित है जब ग्लोबल सिंगल रिफ्रेश की आवश्यकता हो और क्रॉस-रीजन लेटेंसी और विभाजन स्वीकार्य हों।

फॉलो-अप 8: आप कैसे साबित करते हैं कि डिज़ाइन काम करता है?

क्रैश, पॉज, कैश विफलता और वर्ज़न रेस को इंजेक्ट करते हुए सॉफ्ट और हार्ड एक्सपायरी के दौरान प्रति सेकंड 50,000 अनुरोध चलाएं। प्रति की (key) एक सामान्य रिफ्रेश, बजट के भीतर ओरिजिन लोड, अधिकतम 30 सेकंड का पुरानापन, और कोई वर्ज़न रोलबैक न होना सुनिश्चित करें।