बैकएंड इंटरव्यू: आप एक सुरक्षित stale-while-revalidate कैश अनुबंध कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

आप एक CDN और एक एप्लिकेशन कैश के पीछे GET /catalog संचालित करते हैं। डिप्लॉयमेंट के दौरान ओरिजिन धीमा हो सकता है, लेकिन ग्राहक खाली पेज के बजाय थोड़ा पुराना कैटलॉग देखना पसंद करते हैं। टेनेंट डेटा को अलग (isolated) रखते हुए और फ्रेशनेस को मापने योग्य बनाते हुए कैश हेडर और रिवैलिडेशन पाथ डिज़ाइन करें।

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

इंटरव्यूअर क्या जांचता है

क्या आप फ्रेशनेस, पुरानापन (staleness), रिवैलिडेशन और अलग stale-if-error नीति को समझते हैं।
क्या कैश कीज़ (cache keys) टेनेंट, ऑथराइजेशन, लोकेल और कंटेंट नेगोशिएशन के आधार पर बदलती हैं।
क्या समवर्ती मिसेस (concurrent misses) एक ओरिजिन रिक्वेस्ट ट्रिगर करते हैं या थंडरिंग हर्ड (thundering herd) समस्या पैदा करते हैं।
क्या कोई ऑपरेटर पुराने डेटा की डिलीवरी को रद्द कर सकता है और मेट्रिक्स के साथ फ्रेशनेस साबित कर सकता है।

उत्तर देने से पहले स्पष्टीकरण हेतु प्रश्न

क्या रिस्पॉन्स सार्वजनिक, टेनेंट-स्कोप या उपयोगकर्ता-विशिष्ट है? प्राइवेट डेटा को CDN द्वारा बिल्कुल भी साझा नहीं किया जाना चाहिए।
सामान्य रीड्स और ओरिजिन आउटेज के लिए अधिकतम सहन करने योग्य आयु (age) क्या है? ये अलग-अलग फ्रेशनेस और बासी विंडो बन जाती हैं।
क्या मूल्य या अनुमति परिवर्तन ऑब्जेक्ट को तुरंत अमान्य (invalidate) कर सकता है? यदि हाँ, तो केवल TTL पर भरोसा करने के बजाय पर्ज (purge) या वर्जन्ड कीज़ जोड़ें।
क्या वैलिडेटर उपलब्ध हैं? ETag या Last-Modified पूरे रीफैच को एक सशर्त (conditional) रिवैलिडेशन में बदल देता है।

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

"मैं एक फ्रेश विंडो, एक सीमित stale-while-revalidate विंडो और एक अलग stale-if-error विंडो परिभाषित करता हूँ। कैश की में प्रत्येक रिप्रेजेंटेशन और ऑथराइजेशन सीमा शामिल होती है; उपयोगकर्ता-विशिष्ट डेटा प्राइवेट होता है। एक बासी हिट तेज़ी से रिस्पॉन्स देती है और बैकग्राउंड में एक सशर्त रिक्वेस्ट ट्रिगर करती है, जबकि समवर्ती मिसेस को कोएलेस (coalesce) किया जाता है। आपातकालीन परिवर्तन की (key) को पर्ज या वर्ज़न करते हैं। मेट्रिक्स आयु, रिवैलिडेशन परिणाम, stale-if-error उपयोग और क्रॉस-टेनेंट लीकेज परीक्षणों को उजागर करते हैं, और एक ऑपरेटर बासी डेटा की डिलीवरी को अक्षम कर सकता है।"

चरण-दर-चरण विस्तृत विश्लेषण

1. फ्रेशनेस को उपलब्धता से अलग करें

max-age परिभाषित करता है कि संग्रहीत रिस्पॉन्स कितने समय तक फ्रेश रहता है। stale-while-revalidate कैश को बैकग्राउंड में रिवैलिडेट करते समय एक सीमित अंतराल के लिए पुराना रिस्पॉन्स सर्व करने की अनुमति देता है। stale-if-error ओरिजिन त्रुटि के लिए एक अलग उपलब्धता छूट है। कोई भी निर्देश बासी डेटा को सही नहीं बनाता है, और must-revalidate या लागू no-cache नियम वाले रिस्पॉन्स को लापरवाही से दोबारा इस्तेमाल नहीं किया जा सकता है।

एक सार्वजनिक कैटलॉग एक छोटी फ्रेश विंडो और एक लंबी सीमित बासी विंडो का उपयोग कर सकता है। एक अनुमति एंडपॉइंट, खाता शेष (balance), या आपातकालीन मूल्य को private, no-store, एक पर्ज पाथ, या बहुत सख्त नीति का उपयोग करना चाहिए। व्यावसायिक जोखिम विंडो तय करता है, कोई कैश डिफ़ॉल्ट नहीं।

2. एक सुरक्षित कैश की और रिस्पॉन्स अनुबंध बनाएं

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

http

Cache-Control: public, max-age=30, stale-while-revalidate=120, stale-if-error=600
Vary: Accept-Encoding, Accept-Language, X-Tenant-ID
ETag: "catalog-tenant-7-v42"

सर्वर को सत्यापित करना चाहिए कि X-Tenant-ID प्रमाणित रूट या होस्ट से प्राप्त हुआ है, किसी मनमाने क्लाइंट मान से नहीं। यदि किसी टेनेंट सीमा को की में सुरक्षित रूप से दर्शाया नहीं जा सकता है, तो शेयर्ड कैशिंग अक्षम करें।

3. थंडरिंग हर्ड के बिना रिवैलिडेट करें

एक बासी हिट पर, संग्रहीत बॉडी लौटाएं और प्रति कैश की एक रिवैलिडेशन कतारबद्ध करें। एक छोटे लॉक या सिंगल-फ़्लाइट मैप का उपयोग करें ताकि दस हज़ार पाठक दस हज़ार ओरिजिन कॉल न करें। रिवैलिडेटर If-None-Match भेजता है; एक 304 Not Modified बॉडी को बदले बिना फ्रेशनेस को रीफ्रेश करता है, जबकि एक नया 200 ऑब्जेक्ट और वैलिडेटर को बदल देता है।

यदि रिवैलिडेशन किसी क्षणिक (transient) त्रुटि के साथ विफल हो जाता है, तो पुराने ऑब्जेक्ट को केवल stale-if-error सीमा के भीतर रखें। विफलता और आयु रिकॉर्ड करें। इसके टाइमर को बार-बार रीसेट करके बासी विंडो को अनिश्चित काल तक न बढ़ाएं।

4. अमान्यकरण (Invalidation) को स्पष्ट बनाएं

TTL एक सुरक्षा तंत्र है, आपातकालीन नियंत्रण नहीं। मूल्य या अनुमति परिवर्तन को एक वर्जन्ड अमान्यकरण इवेंट प्रकाशित करना चाहिए या प्रभावित कीज़ को पर्ज करना चाहिए। राइट पाथ इवेंट प्रकाशित करने से पहले नए संस्करण को कमिट कर सकता है; उपभोक्ताओं को आइडम्पोटेंट और पुन: प्रयोज्य (replayable) होना चाहिए। यदि पर्ज की पुष्टि नहीं की जा सकती है, तो API एक छोटी must-revalidate अवधि जोड़ सकता है या प्रभावित टेनेंट के लिए कैश को बायपास कर सकता है।

5. नीति को मापें और संचालित करें

रिस्पॉन्स आयु, फ्रेश-हिट अनुपात, stale-while-revalidate हिट अनुपात, stale-if-error गणना, रिवैलिडेशन लेटेंसी, 304 दर, ओरिजिन त्रुटि दर, लॉक विवाद और कैश-की कार्डिनैलिटी को ट्रैक करें। अधिकतम आयु के करीब पहुंचने, अप्रत्याशित stale-if-error स्पाइक्स और क्रॉस-टेनेंट टेस्ट विफलताओं पर अलर्ट सेट करें।

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

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

मैं डेटा को वर्गीकृत करके शुरुआत करूँगा। एक सार्वजनिक, टेनेंट-स्कोप्ड कैटलॉग में max-age=30, stale-while-revalidate=120, और एक अलग से उचित stale-if-error=600 हो सकता है; उपयोगकर्ता-विशिष्ट या अनुमति डेटा प्राइवेट या अनकैश होना चाहिए। की में टेनेंट और रिप्रेजेंटेशन आयाम शामिल हैं, और रिस्पॉन्स में एक वैलिडेटर होता है।

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

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

त्रुटि: खाता या अनुमति डेटा पर stale-while-revalidate लागू करना → यह क्यों विफल होता है: एक तेज़ बासी रिस्पॉन्स एक अमान्य ऑथराइजेशन निर्णय को उजागर कर सकता है → समाधान: संवेदनशील डेटा को प्राइवेट या अनकैश रखें।
त्रुटि: की से टेनेंट या लोकेल को छोड़ना → यह क्यों विफल होता है: एक रिप्रेजेंटेशन दूसरी सीमा पर सर्व किया जा सकता है → समाधान: प्रत्येक की आयाम प्राप्त करें और उसका परीक्षण करें।
त्रुटि: प्रत्येक विफल रिवैलिडेशन के बाद बासी टाइमर को रीफ्रेश करना → यह क्यों विफल होता है: आउटेज डेटा हमेशा बना रह सकता है → समाधान: एक पूर्ण बासी समय सीमा लागू करें।
त्रुटि: प्रत्येक बासी पाठक के लिए एक ओरिजिन रिक्वेस्ट भेजना → यह क्यों विफल होता है: बासी बर्स्ट एक थंडरिंग हर्ड बन जाता है → समाधान: प्रति की सिंगल-फ़्लाइट रिवैलिडेशन का उपयोग करें।
त्रुटि: TTL को आपातकालीन अमान्यकरण के रूप में मानना → यह क्यों विफल होता है: तत्काल परिवर्तन समाप्ति की प्रतीक्षा करते हैं → समाधान: पर्ज या वर्ज़न इवेंट प्रकाशित करें और पूरा होने का सत्यापन करें।

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

केवल stale-if-error का उपयोग क्यों न करें?

यह केवल तभी मदद करता है जब ओरिजिन रिक्वेस्ट में कोई त्रुटि आती है। stale-while-revalidate सफल रीफ्रेश चलने के दौरान एक पुराना रिस्पॉन्स सर्व करके सामान्य लेटेंसी में सुधार करता है। वे विभिन्न स्थितियों को हल करते हैं और उन्हें अलग सीमाओं और मेट्रिक्स की आवश्यकता होती है।

क्या होता है जब पर्ज के दौरान वैलिडेटर बदल जाता है?

ऑब्जेक्ट को वर्ज़न करें और पर्ज इवेंट को आइडम्पोटेंट बनाएं। पुराने वैलिडेटर को देखने वाले रिवैलिडेशन को नए संस्करण को अधिलेखित (overwrite) नहीं करना चाहिए; कैश प्रविष्टि को बदलने से पहले ऑब्जेक्ट संस्करणों या कमिट टाइमस्टैम्प की तुलना करें। यदि क्रम अनिश्चित है, तो उस की के लिए कैश को संक्षिप्त रूप से बायपास करें।

क्या कोई CDN Vary: Authorization के साथ प्रमाणित रिस्पॉन्स को कैश कर सकता है?

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