सिस्टम डिज़ाइन इंटरव्यू: आप एक ग्लोबल कंटेंट डिलीवरी नेटवर्क (CDN) को कैसे डिज़ाइन करेंगे?

समस्या और लागू होने वाले परिदृश्य

50 पॉइंट्स ऑफ़ प्रेज़ेंस (PoPs) के साथ एक मल्टी-टेनेंट पुल कंटेंट डिलीवरी नेटवर्क डिज़ाइन करें। पीक के समय इस पर प्रति सेकंड 2 मिलियन GET और HEAD रिक्वेस्ट्स आती हैं, और औसत कैश करने योग्य GET रिस्पॉन्स 256 KiB है। ग्राहक ऑरिजिन सुरक्षित रूप से कुल 20,000 फेच प्रति सेकंड स्वीकार कर सकते हैं। CDN कंटेंट-हैश किए गए एसेट्स, छवियों, वीडियो सेगमेंट और स्थिर URLs पर म्यूटेबल दस्तावेज़ों को सर्व करता है।

लक्ष्य सामान्य परिस्थितियों में कैश्ड रिस्पॉन्स के लिए 50 मिलीसेकंड से कम का p99 टाइम टू फर्स्ट बाइट (TTFB), 99.99% रिक्वेस्ट उपलब्धता, और 60 सेकंड के भीतर 99% स्वस्थ PoPs पर प्रत्येक पर्ज का लागू होना है। पूरा प्रोपेगेशन और धीमे (lagging) PoPs अवलोकनीय (observable) होने चाहिए। ये मान इंटरव्यू की मान्यताएं हैं, किसी प्रोवाइडर के बारे में दावे नहीं हैं।

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

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

पहला संकेत यह है कि उम्मीदवार कंट्रोल प्लेन को डेटा प्लेन से अलग करता है या नहीं। टेनेंट ऑनबोर्डिंग, ऑरिजिन कॉन्फ़िगरेशन, प्रमाणपत्र, कैश नियम और पर्ज कमांड्स को टिकाऊ प्रबंधन वर्कफ़्लो की आवश्यकता होती है। जब वह प्रबंधन पथ अनुपलब्ध हो, तब भी रिक्वेस्ट्स को अंतिम-ज्ञात-अच्छे (last-known-good) कॉन्फ़िगरेशन से सर्व होते रहना चाहिए।

दूसरा संकेत कैश सीमा की शुद्धता है। एक कैश की (cache key) जो किसी रिप्रजेंटेशन डाइमेंशन को छोड़ देती है, वह भाषाओं, एन्कोडिंग्स, डिवाइसेस या टेनेंट्स के बीच रिस्पॉन्स को लीक या दूषित कर सकती है। एक ऐसी की (key) जिसमें प्रत्येक कुकी और हेडर शामिल होता है, कैश को तब तक खंडित (fragment) करती है जब तक कि लगभग हर रिक्वेस्ट मिस न हो जाए। उत्तर में यह परिभाषित होना चाहिए कि कौन सी रिक्वेस्ट्स योग्य हैं, कौन से डाइमेंशन्स रिप्रजेंटेशन में बदलाव लाते हैं, और कौन से निजी रिस्पॉन्स शेयर्ड स्टोरेज को बाईपास करते हैं।

तीसरा संकेत ऑरिजिन की सुरक्षा है। 50 PoPs के साथ, एक नया लोकप्रिय ऑब्जेक्ट पुनः प्रयासों (retries) से पहले भी 50 एक साथ कोल्ड फिल्स बना सकता है। प्रत्येक टियर पर रिक्वेस्ट कोलेसिंग (request coalescing), क्षेत्रीय शील्ड्स, सीमित ऑरिजिन समवर्तीता (concurrency), और रिट्राई बजट उस पथ के विभिन्न हिस्सों को हल करते हैं। कोई भी विफलता मोड 2 मिलियन एज रिक्वेस्ट्स प्रति सेकंड को चुपचाप ऑरिजिन ट्रैफ़िक में परिवर्तित नहीं करना चाहिए।

चौथा संकेत इनवैलिडेशन की शुद्धता है। एक पर्ज जो केवल वर्तमान बाइट्स को हटाता है, वह एक पुराने भराव (fill) के साथ रेस कर सकता है और पुराने (stale) कंटेंट को फिर से प्रकट होने दे सकता है। मजबूत उत्तर एक क्रमित जेनरेशन (generation) या टॉम्बस्टोन (tombstone) का उपयोग करते हैं, डिलीवरी को इडेम्पोटेंट (idempotent) बनाते हैं, और सामान्य प्रोपेगेशन SLO और लॉन्ग टेल दोनों को मापते हैं।

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

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• क्या CDN स्रोत ऑब्जेक्ट्स का मालिक है? नहीं। यह एक पुल CDN है; ग्राहक ऑरिजिन ही प्रामाणिक (authoritative) रहते हैं।
• कौन से मेथड्स कैश करने योग्य हैं? GET और HEAD से शुरुआत करें। असुरक्षित मेथड्स सीधे पास हो जाते हैं और इस बेसलाइन द्वारा उन्हें कभी भी शेयर्ड कैश में नहीं रखा जाता है।
• कौन सा कंटेंट निजी है? ऑथराइजेशन या उपयोगकर्ता-विशिष्ट कुकीज़ वाली रिक्वेस्ट्स शेयर्ड कैशिंग को बाईपास करती हैं, जब तक कि कोई टेनेंट समीक्षा की गई, स्पष्ट विभाजन नीति प्रदान न करे।
• म्यूटेबल कंटेंट कितना ताज़ा होना चाहिए? प्रत्येक रूट एक TTL और कोई भी सीमित स्टेल विंडो परिभाषित करता है। एक पर्ज तत्काल परिवर्तनों को लक्षित करता है; यह ऑथराइजेशन या निरस्तीकरण (revocation) जांच का विकल्प नहीं है।
• क्या प्रत्येक क्वेरी पैरामीटर सार्थक है? नहीं। टेनेंट उन पैरामीटर्स को अनुमति सूची (allowlist) में डालता है जो रिप्रजेंटेशन को बदलते हैं और कैनोनिकलाइजेशन के बाद ज्ञात ट्रैकिंग पैरामीटर्स को हटा सकता है।
• क्या बाइट रेंज की आवश्यकता है? बड़े मीडिया के लिए हाँ। की और मेटाडेटा को मान्य श्रेणियों (validated ranges) से पूर्ण ऑब्जेक्ट्स को अलग करना चाहिए, और ऑरिजिन को स्थिर वैलिडेटर या वर्जन्ड URLs प्रदान करने चाहिए।
• निकटतम PoP कैसे चुना जाता है? DNS और/या एनीकास्ट (anycast) उपयोगकर्ता को एक सुलभ PoP पर रूट करते हैं। BGP पाथ चयन भौगोलिक निकटता की गारंटी नहीं है, इसलिए स्वास्थ्य और मापी गई लेटेंसी आवश्यक बनी रहती है।
• कंट्रोल प्लेन विफल होने पर क्या होता है? मौजूदा ट्रैफ़िक हस्ताक्षरित (signed) अंतिम-ज्ञात-अच्छे कॉन्फ़िगरेशन के साथ जारी रहता है; असुरक्षित परिवर्तन विफल (fail closed) हो जाते हैं और बाद में लागू होने के लिए कतारबद्ध हो जाते हैं।
• क्या ऑरिजिन आउटेज के दौरान स्टेल डेटा सर्व किया जा सकता है? केवल स्पष्ट stale-if-error अनुमति और एक सीमित अधिकतम आयु वाले रूट्स के लिए।
• पर्ज पूरा होने का क्या अर्थ है? 60-सेकंड का लक्ष्य 99% स्वस्थ PoPs को कवर करता है; सिस्टम प्रत्येक पावती (acknowledgement), धीमे PoP, रिट्राई और प्रोब परिणाम को अलग से रिकॉर्ड करता है।

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

"मैं कंट्रोल और डेटा प्लेन को अलग करता हूँ। DNS और एनीकास्ट एक स्वस्थ PoP पर ले जाते हैं; एज एक हस्ताक्षरित टेनेंट कॉन्फ़िगरेशन का चयन करता है, एक अनुमत की (key) को कैनोनिकलाइज़ करता है, और RAM फिर SSD की जांच करता है। मिसेस एज और क्षेत्रीय शील्ड पर एकजुट (coalesce) होते हैं, जिसके बाद बजेटेड ऑरिजिन फेच होता है; स्टेल सर्विंग स्पष्ट सीमाओं का पालन करती है। इम्यूटेबल एसेट्स वर्जन्ड URLs का उपयोग करते हैं। म्यूटेबल URLs एक क्रमित पर्ज जेनरेशन और टॉम्बस्टोन का उपयोग करते हैं, और पब्लिकेशन से पहले फिल्स जेनरेशन्स की तुलना करते हैं ताकि पुराने बाइट्स वापस न आ सकें। मैं रिक्वेस्ट और बाइट हिट दर, ऑरिजिन लोड, p99 हिट TTFB, स्टेल आयु, पर्ज लैग और आउटेज व्यवहार को सत्यापित करता हूँ।"

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

चरण 1: ट्रैफ़िक और ऑरिजिन बजट की गणना करें

पीक मिक्स के लिए एक योजना सीमा के रूप में औसत GET आकार का उपयोग करते हुए, प्रोटोकॉल ओवरहेड से पहले रिस्पॉन्स बैंडविड्थ है:

2,000,000 requests/s × 256 KiB × 8 = 4.19 Tb/s

यदि वह पीक एक दिन के लिए बना रहे, तो यह लगभग 45.3 PB एज रिस्पॉन्स बाइट्स का प्रतिनिधित्व करेगा। 50 PoPs में सरल औसत 40,000 रिक्वेस्ट्स/सेकंड और 10.5 GB/s प्रति PoP है, लेकिन वास्तविक ट्रैफ़िक भौगोलिक और कालिक रूप से विषम (skewed) होता है। इसलिए क्षमता नियोजन मापे गए प्रति-PoP पीक, हेडरूम, ऑब्जेक्ट-आकार पर्सेंटाइल और विफलता पुनर्वितरण का उपयोग करता है; औसत केवल एक बेसलाइन है।

ऑरिजिन सीमा एज रिक्वेस्ट पीक का 1% है:

20,000 / 2,000,000 = 1%

इसका मतलब यह नहीं है कि केवल एज हिट-रेट का लक्ष्य 99% है। शील्ड हिट्स, अनकैशेबल रूट्स, फिल्स, रीवैलिडेशन और रिट्राई सभी समान ऑरिजिन बजट की खपत करते हैं। ऑरिजिन-फेसिंग शेड्यूलर को प्रति-टेनेंट, प्रति-ऑरिजिन और वैश्विक समवर्तीता और रिक्वेस्ट-रेट सीमाओं की आवश्यकता होती है।

चरण 2: कंट्रोल और डेटा प्लेन को अलग करें

कंट्रोल प्लेन टेनेंट्स, डोमेन, ऑरिजिन पहचान, प्रमाणपत्र, कैश नीतियां, कैनोनिकलाइजेशन नियम, स्टेल सीमाएं, हस्ताक्षरित-URL कीज़ और कॉन्फ़िगरेशन वर्जन्स को संग्रहीत करता है। एक मान्य परिवर्तन को स्थायी रूप से कमिट किया जाता है, एक हस्ताक्षरित स्नैपशॉट में संकलित किया जाता है, और एक वर्जन्ड स्ट्रीम के माध्यम से वितरित किया जाता है। PoPs लागू वर्जन्स को स्वीकार (acknowledge) करते हैं। सर्टिफिकेट प्राइवेट कीज़ एक समर्पित सीक्रेट और की प्रबंधन सीमा का उपयोग करती हैं और सामान्य कॉन्फ़िगरेशन स्टोरेज से बाहर रहती हैं।

डेटा प्लेन TLS, टेनेंट लुकअप, नीति प्रवर्तन, रिक्वेस्ट सामान्यीकरण, कैशिंग, ऑरिजिन एक्सेस और लॉग्स को संभालता है। यह कैश हिट पर कंट्रोल-प्लेन डेटाबेस को कभी भी सिंक्रोनस रूप से कॉल नहीं करता है। PoPs कंट्रोल-प्लेन आउटेज के दौरान अंतिम-ज्ञात-अच्छा हस्ताक्षरित स्नैपशॉट बनाए रखते हैं। एक स्टेल कॉन्फ़िगरेशन का जीवनकाल सीमित होता है; उस जीवनकाल के बाद समाप्त हो चुके प्रमाणपत्र, निरस्त टेनेंट्स और अस्पष्ट सुरक्षा नीति विफल (fail closed) हो जाती है।

चरण 3: ट्रैफ़िक रूट करें और टेनेंट्स को अलग करें

DNS क्षेत्रीय नाम या एनीकास्ट पते लौटा सकता है; एक एनीकास्ट नेटवर्क कई PoPs से एक ही पते की घोषणा कर सकता है। रूटिंग एक सुलभ नेटवर्क पथ चुनती है, फिर सेवा स्वास्थ्य खराब PoP को हटा देता है और इसे दूसरे स्थान पर भेज देता है। डिज़ाइन रूट परिवर्तनों, फ़ेलओवर लोड और लेटेंसी को ट्रैक करता है क्योंकि "निकटतम" एक देखा गया परिणाम है, न कि BGP गारंटी।

एज पर, SNI और सामान्यीकृत Host किसी भी कैश लुकअप से पहले एक टेनेंट को मैप करते हैं। टेनेंट ID प्रत्येक कैश नेमस्पेस का एक अंतर्निहित पहला घटक है। ऑरिजिन केवल mTLS, हस्ताक्षरित रिक्वेस्ट्स, निजी कनेक्टिविटी, या एक रोटेटिंग सीक्रेट के माध्यम से प्रमाणित CDN ट्रैफ़िक स्वीकार करते हैं, और उन्हें सार्वजनिक रूप से बाईपास करने योग्य नहीं रहना चाहिए। SSRF को रोकने के लिए ऑरिजिन पते और रीडायरेक्ट अनुमति सूची (allowlist) में होने चाहिए।

चरण 4: कैश पात्रता और की (Key) को परिभाषित करें

बेसलाइन केवल तभी सफल GET और HEAD रिस्पॉन्स को स्वीकार करता है जब रूट नीति और HTTP फ़ील्ड साझा पुन: उपयोग की अनुमति देते हैं। private, no-store, ऑथराइजेशन, उपयोगकर्ता-विशिष्ट कुकीज़, Set-Cookie, और असमर्थित Vary मान सामान्य रूप से स्टोरेज को बाईपास करते हैं। नकारात्मक रिस्पॉन्स केवल एक संक्षिप्त, स्थिति-विशिष्ट TTL के लिए कैश किए जा सकते हैं ताकि क्षणिक विफलता एक लंबा आउटेज न बन जाए।

एक वैचारिक की (key) है:

tenant_id | canonical_scheme_host | normalized_path | selected_query |
encoding_variant | approved_vary_dimensions | object_generation

कैनोनिकलाइजेशन नीति, लुकअप, लॉगिंग, फिल और पर्ज से पहले एक बार होता है। केवल वे क्वेरी पैरामीटर और हेडर जो वास्तव में बाइट्स बदलते हैं, की में प्रवेश करते हैं। Accept-Language जोड़ना तब सही होता है जब ऑरिजिन भाषा के अनुसार भिन्न होता है; मनमाना कुकीज़ या User-Agent जोड़ने से कार्डिनैलिटी बढ़ सकती है। रिस्पॉन्स का Vary रूट के अनुमत डाइमेंशन्स से मेल खाना चाहिए, अन्यथा रिस्पॉन्स कैशिंग को बाईपास कर देता है।

ताजगी टेनेंट नीति और HTTP सिमेंटिक्स का पालन करती है: ताज़ा प्रविष्टियां सीधे वापस आती हैं; बासी प्रविष्टियां ETag या Last-Modified के साथ पुन: मान्य होती हैं; stale-while-revalidate और stale-if-error का उपयोग केवल स्पष्ट सीमाओं के भीतर किया जाता है। no-cache का अर्थ है पुन: उपयोग से पहले पुन: मान्य करना, जबकि no-store का अर्थ है स्टोर न करना। कैश नीति को ऑरिजिन के सख्त गोपनीयता निर्देश को कमजोर नहीं करना चाहिए।

चरण 5: RAM, SSD, शील्ड और ऑरिजिन फिल पाथ बनाएं

प्रत्येक PoP हॉट मेटाडेटा और छोटे ऑब्जेक्ट्स को RAM में और एक बड़े एडमिशन-नियंत्रित SSD कैश में रखता है। एडमिशन और निष्कासन (eviction) रिक्वेस्ट दर, बाइट आकार, नवीनता (recency) और फेच लागत पर विचार करते हैं ताकि बड़े, कोल्ड ऑब्जेक्ट्स का एक स्कैन उपयोगी वर्किंग सेट को बाहर न निकाल सके। ऑरिजिन आधिकारिक रहता है; एज कैश खोना एक प्रदर्शन घटना है, डेटा हानि नहीं।

मिस होने पर, एक सिंगलफ्लाइट टेबल सटीक की (key) के लिए कॉल करने वालों को एकजुट (coalesce) करती है। एक कॉलर क्षेत्रीय शील्ड से पूछता है; फॉलोअर्स एक सीमित समय तक प्रतीक्षा करते हैं या अनुमत स्टेल प्रविष्टि का उपयोग करते हैं। शील्ड कई PoPs में लुकअप और कोलेसिंग को दोहराती है। केवल इसका चुना हुआ फिल ऑरिजिन शेड्यूलर में प्रवेश करता है। यह दूसरी कोलेसिंग सीमा एक कोल्ड ऑब्जेक्ट को प्रति PoP एक स्वतंत्र ऑरिजिन फेच बनाने से रोकती है।

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

चरण 6: पर्ज और फिल रेस को सुरक्षित बनाएं

इम्यूटेबल एसेट्स के लिए कंटेंट-एड्रेस्ड फ़ाइल नाम डिफ़ॉल्ट हैं: नए बाइट्स प्रकाशित करने से एक नया URL बनता है, और पुराने URLs स्वाभाविक रूप से समाप्त हो सकते हैं। स्थिर URLs को एक स्पष्ट पर्ज API की आवश्यकता होती है जो एक सटीक ऑब्जेक्ट, एक अनुमोदित उपसर्ग (prefix) या टैग, और एक टेनेंट-स्कॉप्ड आपातकालीन पर्ज का समर्थन करती है। व्यापक पर्ज दर-सीमित (rate-limited) होते हैं और मजबूत ऑथराइजेशन की आवश्यकता होती है क्योंकि वे एक वैश्विक मिस तूफान पैदा कर सकते हैं।

पर्ज समन्वयक स्वीकार करने से पहले एक टिकाऊ क्रमित लॉग में {tenant, selector, generation, issued_at} को कमिट करता है। PoPs इस घटना को इडेम्पोटेंट रूप से लागू करते हैं, चयनकर्ता की न्यूनतम जेनरेशन को आगे बढ़ाते हैं, मेल खाने वाले बाइट्स को हटाते हैं, और पुराने फिल्स और विलंबित घटनाओं को कवर करने के लिए पर्याप्त समय तक एक टॉम्बस्टोन बनाए रखते हैं। वे लागू की गई जेनरेशन की रिपोर्ट करते हैं। पदानुक्रमित (hierarchical) फैन-आउट, रिट्राई और क्षेत्रीय रिले एक धीमे PoP को सामान्य पथ को अवरुद्ध करने से रोकते हैं।

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

API स्वीकृत, 99%-प्रोपेगेटेड और पूर्ण-या-समाप्त स्थितियों की अलग-अलग रिपोर्ट करता है। सिंथेटिक प्रोब्स क्षेत्रों से पर्ज की गई की (key) का अनुरोध करते हैं और वर्ज़न हेडर या कंटेंट हैश को मान्य करते हैं। सुरक्षा निरस्तीकरण (revocation) अभी भी एक आधिकारिक ऑनलाइन जांच या अलग से सीमित टोकन जीवनकाल से संबंधित है; 60-सेकंड का कैश-पर्ज SLO तत्काल निरस्तीकरण नहीं है।

चरण 7: ओवरलोड और विफलताओं को स्पष्ट रूप से संभालें

• PoP विफलता: रूट को वापस लें या विज्ञापन देना बंद करें, स्वस्थ PoPs पर ड्रेन करें, और पुनर्वितरित ट्रैफ़िक के लिए क्षमता आरक्षित करें।
• SSD का नुकसान: एडमिशन कंट्रोल के माध्यम से धीरे-धीरे पुनर्निर्माण करें; प्रत्येक ऑब्जेक्ट को वार्म न करें या शील्ड को बाईपास न करें।
• शील्ड की विफलता: एक सेकेंडरी शील्ड चुनें; यदि डायरेक्ट-ऑरिजिन फ़ॉलबैक की अनुमति है, तो समान ऑरिजिन बजट बनाए रखें।
• ऑरिजिन टाइमआउट या 5xx: केवल वहीं सीमित स्टेल कंटेंट सर्व करें जहां नीति अनुमति देती है; अन्यथा एक स्पष्ट त्रुटि लौटाएं और रिट्राई प्रवर्धन (amplification) से बचें।
• कंट्रोल-प्लेन आउटेज: अंतिम-ज्ञात-अच्छे हस्ताक्षरित कॉन्फ़िगरेशन से सर्व करना जारी रखें; सुरक्षित परिवर्तनों को कतारबद्ध करें और सुरक्षा-संवेदनशील म्यूटेशन को अस्वीकार करें जिन्हें सत्यापित नहीं किया जा सकता है।
• पर्ज-स्ट्रीम में देरी: इडेम्पोटेंट रूप से पुन: प्रयास करें, पिछड़ने वाले PoPs को प्रदर्शित करें, और जब कोई महत्वपूर्ण जेनरेशन ज्ञात हो लेकिन बाइट्स भरोसेमंद न हों, तो प्रभावित की (key) को बाईपास या पुन: मान्य करें।
• हॉट-ऑब्जेक्ट में अचानक वृद्धि: फिल्स को कोलेस करें, कैश प्रक्रियाओं में ऑब्जेक्ट को रेप्लिकेट करें, एक प्रक्रिया को NIC या लॉक संतृप्ति से बचाएं, और अपमानजनक टेनेंट्स को दर-सीमित करें।

चरण 8: पूरे सिस्टम को सुरक्षित और सत्यापित करें

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

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

सत्यापन में सभी 50 PoPs से एक हॉट-ऑब्जेक्ट कोल्ड स्टार्ट, जानबूझकर धीमे फिल के साथ रेस करने वाला पर्ज, डुप्लिकेट और आउट-ऑफ़-ऑर्डर पर्ज इवेंट्स, एक विषाक्त (poisoned) Vary, ऑथराइजेशन और कुकी बाईपास, आंशिक रेंज फिल्स, एक SSD रीस्टार्ट, शील्ड हानि, ऑरिजिन थ्रॉटलिंग, PoP वापसी और एक कंट्रोल-प्लेन आउटेज शामिल हैं। स्वीकृति जांच में सामान्य परिस्थितियों में 50 मिलीसेकंड से कम कैश्ड p99 TTFB, 99.99% की रिक्वेस्ट उपलब्धता, 20,000 प्रति सेकंड या उससे कम पर ऑरिजिन फेच, और बिना किसी बासी पुनरुत्थान के 60 सेकंड के भीतर पर्ज लागू करने वाले 99% स्वस्थ PoPs शामिल हैं।

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

"मैं क्षमता सीमा से शुरुआत करूँगा। 256 KiB पर प्रति सेकंड दो मिलियन रिक्वेस्ट्स पीक रिस्पॉन्स ट्रैफ़िक का लगभग 4.19 Tb/s है। ऑरिजिन केवल एज रिक्वेस्ट वॉल्यूम का 1% स्वीकार कर सकते हैं, इसलिए ऑरिजिन सुरक्षा एक सख्त इनवेरिएंट (invariant) है, न कि कोई वैकल्पिक अनुकूलन।

मैं एक टिकाऊ कंट्रोल प्लेन को सर्विंग डेटा प्लेन से अलग करता हूँ। टेनेंट कॉन्फ़िगरेशन, प्रमाणपत्र, ऑरिजिन पहचान, कैश नियम और पर्ज वर्जन्ड और ऑडिट किए जाते हैं। PoPs प्रत्येक रिक्वेस्ट पर उस डेटाबेस को क्वेरी करने के बजाय हस्ताक्षरित अंतिम-ज्ञात-अच्छे कॉन्फ़िगरेशन के साथ सर्व करते हैं। DNS और एनीकास्ट उपयोगकर्ताओं को एक स्वस्थ PoP पर रूट करते हैं; SNI और Host एक नेमस्पेस कैश लुकअप से पहले टेनेंट की पहचान करते हैं।

की (key) में टेनेंट, कैनोनिकल URL, केवल वे क्वेरी और हेडर डाइमेंशन्स शामिल हैं जो रिप्रजेंटेशन को बदलते हैं, और एक जेनरेशन शामिल है। निजी, अधिकृत, no-store और असुरक्षित रिस्पॉन्स शेयर्ड कैश को बाईपास करते हैं। एक हिट RAM या SSD से आता है। एक मिस एज पर एकजुट होता है, एक क्षेत्रीय शील्ड को भेजा जाता है, फिर से एकजुट होता है, और प्रति-ऑरिजिन और वैश्विक बजट के माध्यम से स्वीकार किया जाता है। ताज़ा, पुन: मान्य और सीमित-स्टेल पथ अलग-अलग हैं।

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

मैं रिक्वेस्ट और बाइट हिट दरों, ऑरिजिन QPS, p99 हिट TTFB, स्टेल आयु, पर्ज लैग और कॉन्फ़िगरेशन वर्जन्स के साथ डिज़ाइन को साबित करूँगा। फिर मैं एक हॉट कोल्ड मिस, पर्ज/फिल रेस, PoP और शील्ड विफलताओं, ऑरिजिन थ्रॉटलिंग, आउट-ऑफ़-ऑर्डर पर्ज इवेंट्स, कैश-की पॉइज़निंग, और एक कंट्रोल-प्लेन आउटेज को इंजेक्ट करूँगा, जिसमें चार बताए गए SLOs को स्वीकृति मानदंड के रूप में रखा जाएगा।"

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

• भौगोलिक रूप से निकटतम PoP को गारंटीकृत कहना → BGP नेटवर्क पथों का चयन करता है, सीधी रेखा की दूरी का नहीं → लेटेंसी और स्वास्थ्य को मापें, और रूट वापसी और फ़ेलओवर डिज़ाइन करें।
• की में प्रत्येक रिक्वेस्ट हेडर को शामिल करना → कार्डिनैलिटी बढ़ जाती है और अधिकांश ट्रैफ़िक मिस हो जाता है → केवल रिप्रजेंटेशन-परिवर्तनकारी डाइमेंशन्स को अनुमति सूची में रखें और असमर्थित Vary को अस्वीकार करें।
• नेमस्पेस से टेनेंट पहचान को छोड़ना → समान URLs टेनेंट सीमाओं को पार कर सकते हैं → लुकअप से पहले टेनेंट प्राप्त करें और इसे एक अंतर्निहित की प्रीफ़िक्स बनाएं।
• जेनरेशन के बिना पर्ज पर बाइट्स हटाना → एक पुराना इन-फ़्लाइट फिल उन्हें फिर से प्रकाशित कर सकता है → एक टॉम्बस्टोन को आगे बढ़ाएं और कैश इंसर्शन से पहले जेनरेशन्स की तुलना करें।
• केवल एक एज लॉक जोड़ना → 50 PoPs अभी भी 50 ऑरिजिन फिल्स जारी कर सकते हैं → एक शील्ड पर फिर से कोलेस करें और ऑरिजिन-व्यापी बजट बनाए रखें।
• प्रत्येक विफल ऑरिजिन रिक्वेस्ट का पुनः प्रयास करना → रिट्राई आउटेज को बढ़ा देते हैं → समय सीमा, सीमित बजट, जिटर, और रूट-विशिष्ट स्टेल या त्रुटि व्यवहार का उपयोग करें।
• तत्काल सुरक्षा निरस्तीकरण के लिए पर्ज का उपयोग करना → प्रोपेगेशन में एक मापने योग्य टेल होती है → सुरक्षा निर्णयों के लिए एक आधिकारिक जांच या सीमित क्रेडेंशियल जीवनकाल का उपयोग करें।
• केवल रिक्वेस्ट हिट दर की रिपोर्ट करना → कई छोटे हिट्स महंगे बड़े मिसेस को छिपा सकते हैं → बाइट हिट दर, ऑरिजिन बैंडविड्थ, आकार वितरण, और फेच लागत को भी ट्रैक करें।

फ़ॉलो-अप विस्तृत विश्लेषण

फ़ॉलो-अप 1: आप बड़े वीडियो ऑब्जेक्ट्स और रेंज रिक्वेस्ट्स का समर्थन कैसे करेंगे?

इम्यूटेबल सेगमेंट URLs को प्राथमिकता दें और जहां व्यावहारिक हो वहां पूर्ण सेगमेंट कैश करें। श्रेणियों को संयोजित करने से पहले Content-Range, ऑब्जेक्ट की लंबाई, वैलिडेटर और जेनरेशन को मान्य करें। रेंज की संख्या और प्रवर्धन को सीमित करें, और कभी भी दो रिप्रजेंटेशन्स को आंशिक-ऑब्जेक्ट की (key) साझा न करने दें। बहुत बड़े ऑब्जेक्ट्स के लिए, चंक्स को एक नियंत्रित ग्रिड में संरेखित करें ताकि ओवरलैपिंग रिक्वेस्ट्स मनमाने टुकड़े बनाए बिना बाइट्स का पुन: उपयोग कर सकें।

फ़ॉलो-अप 2: आप कैश-की पॉइज़निंग हमले को कैसे रोकेंगे?

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

फ़ॉलो-अप 3: क्या पर्सनलाइज़्ड HTML को कभी एज पर कैश किया जाना चाहिए?

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

फ़ॉलो-अप 4: आप एक वैश्विक शील्ड और क्षेत्रीय शील्ड्स के बीच कैसे चयन करेंगे?

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

फ़ॉलो-अप 5: आप एक नई कैश-की नीति कैसे लागू करेंगे?

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

फ़ॉलो-अप 6: क्या 99.99% उपलब्धता के लिए मल्टी-CDN आवश्यक है?

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