प्रॉम्प्ट और संदर्भ
एक क्लाइंट को एक अविश्वसनीय नेटवर्क पर कई गीगाबाइट की फ़ाइल अपलोड करने की आवश्यकता है। एक मोबाइल क्लाइंट पुनः प्रयास (retry) कर सकता है या उसी पार्ट को एक साथ (concurrently) सबमिट कर सकता है। सर्विस को प्रगति (progress) दिखानी चाहिए, छूटे हुए पार्ट्स को फिर से सबमिट करने की अनुमति देनी चाहिए, और फ़ाइनलाइज़ेशन से पहले और बाद में कंटेंट की सत्यनिष्ठा (integrity) साबित करनी चाहिए। इंटरव्यू प्रोटोकॉल स्टेट, आइडम्पोटेन्सी (idempotency), चेकसम, लाइफसाइकिल और ऑब्जेक्ट विजिबिलिटी पर केंद्रित है।
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर यह देखना चाहता है कि एक बड़े रिक्वेस्ट को एक रिकवरेबल सेशन में कैसे विभाजित किया जाता है। Google Cloud रिज़्यूमेबल अपलोड को ऐसे मल्टीपल रिक्वेस्ट्स के रूप में परिभाषित करता है जो कम्युनिकेशन फेलियर के बाद भी जारी रह सकते हैं; Amazon S3 मल्टीपार्ट अपलोड में ऑब्जेक्ट को असेंबल करने से पहले पार्ट्स और एक स्पष्ट कम्प्लीट कॉल की आवश्यकता होती है, और यह इनकम्प्लीट अपलोड्स के लिए लाइफसाइकिल क्लीनअप की सिफारिश करता है। एक बेहतरीन उत्तर में ऑथराइजेशन, रेट लिमिट्स और डुप्लिकेट कम्प्लीशन सिमेंटिक्स भी शामिल होते हैं।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
ऑब्जेक्ट का आकार, पार्ट का आकार और कॉनकरेंसी लिमिट्स स्पष्ट करें; क्या क्लाइंट सेशन URL बनाए रख सकता है; क्या ऑब्जेक्ट्स को ओवरराइट या वर्ज़न किया जा सकता है; क्या क्लाइंट पूरी फ़ाइल का डाइजेस्ट प्रदान करता है या सर्विस इसकी गणना करती है; और सेशन रिटेंशन, कैंसलेशन, एब्यूज़ और टेनेंट-कोटा नीतियां क्या हैं। एक प्री-साइन्ड (presigned) URL स्वचालित रूप से व्यावसायिक ऑथराइजेशन नहीं ले जाता है।
30-सेकंड का उत्तर ढांचा
कहें: "मैं create-session, upload-part, status, complete, और cancel ऑपरेशन्स एक्सपोज़ करूँगा। सेशन टेनेंट, ऑब्जेक्ट की (key), साइज़, पार्ट रूल्स, एक्सपायरी और चेकसम पॉलिसी को बाइंड करता है। प्रत्येक पार्ट (uploadId, partNumber, checksum) द्वारा आइडम्पोटेंट होता है। कम्प्लीशन लगातार पार्ट्स और संपूर्ण-ऑब्जेक्ट डाइजेस्ट को सत्यापित करता है, फिर एटॉमिक रूप से एक ऑब्जेक्ट वर्ज़न प्रकाशित करता है। एक वर्कर समाप्त (expired) सेशन्स को साफ़ करता है; निर्माण पर और प्रत्येक पार्ट रिक्वेस्ट पर ऑथराइजेशन, कोटा और रेट लिमिट्स की जाँच की जाती है।"
चरण-दर-चरण गहन विश्लेषण
1. अपलोड सेशन बनाएं और अधिकृत करें
POST /uploads टेनेंट कोटा, ऑब्जेक्ट साइज़, कंटेंट टाइप और डेस्टिनेशन परमिशन की जाँच करता है, फिर एक रैंडम uploadId, पार्ट साइज़, एक्सपायरी और स्कोप्ड अपलोड क्रेडेंशियल्स लौटाता है। सेशन अपेक्षित साइज़, ऑब्जेक्ट की, वर्ज़न पॉलिसी और चेकसम एल्गोरिदम रिकॉर्ड करता है; क्लाइंट कोई मनमाना स्टोरेज पाथ नहीं चुन सकता है।
2. आइडम्पोटेंट पार्ट्स और स्टेटस डिज़ाइन करें
PUT /uploads/{id}/parts/{n} पार्ट की लंबाई और चेकसम वहन करता है। सर्विस uploadId + partNumber के लिए नवीनतम मान्य मेटाडेटा संग्रहीत करती है; समान डाइजेस्ट वाला डुप्लिकेट सफलता लौटाता है, जबकि एक अलग डाइजेस्ट कॉन्फ्लिक्ट लौटाता है और क्लाइंट से स्टेटस रिफ्रेश करने के लिए कहता है। GET /uploads/{id} किसी अन्य टेनेंट के डेटा को उजागर किए बिना कन्फर्म किए गए पार्ट्स, साइज़ और अगली कार्रवाई लौटाता है।
3. डेटा इंटीग्रिटी सत्यापित करें
प्रत्येक अपलोड पर लंबाई और पार्ट चेकसम को मान्य करें, फिर कम्प्लीशन के समय लगातार पार्ट नंबर्स, कुल लंबाई और संपूर्ण-ऑब्जेक्ट डाइजेस्ट को मान्य करें। Amazon S3 पार्ट या कम्पोजिट चेकसम का दस्तावेजीकरण करता है; किसी भी बेमेल (mismatch) को प्रकाशन रोकना चाहिए। सेशन में एल्गोरिदम और एन्कोडिंग संग्रहीत करें ताकि क्लाइंट और सर्विस डाइजेस्ट की अलग-अलग व्याख्या न करें।
4. पूर्ण करें और दृश्यता (visibility) को नियंत्रित करें
POST /uploads/{id}/complete एक ऑर्डर्ड पार्ट लिस्ट और वैकल्पिक पूरी-फ़ाइल डाइजेस्ट रखता है। कम्प्लीशन आइडम्पोटेंट है: समान सूची वही ऑब्जेक्ट वर्ज़न लौटाती है, जबकि एक परस्पर विरोधी (conflicting) सूची अस्वीकार कर दी जाती है। स्टोरेज द्वारा ऑब्जेक्ट को असेंबल और सत्यापित करने के बाद ही डेटाबेस रिकॉर्ड UPLOADING से READY में जाता है; रीड्स कभी भी आंशिक ऑब्जेक्ट को उजागर नहीं करते हैं।
5. रद्द करें, समाप्त करें, और अनाथ (orphaned) पार्ट्स को साफ़ करें
क्लाइंट स्पष्ट रूप से रद्द कर सकता है। एक वर्कर एक्सपायर्ड सेशन्स को स्कैन करता है, स्टोरेज एबॉर्ट ऑपरेशन को कॉल करता है, और अपलोड किए गए पार्ट्स को हटा देता है। क्लीनअप अपने आप में आइडम्पोटेंट और पुनः प्रयास योग्य (retryable) है, जिसमें अंतिम त्रुटि और लागत मेट्रिक्स रिकॉर्ड किए जाते हैं। S3 नोट करता है कि इनकम्प्लीट पार्ट्स पर स्टोरेज शुल्क लगता है, इसलिए एक लाइफसाइकिल नियम एक अंतिम सुरक्षा जाल (safety net) है, न कि एप्लिकेशन स्टेट का प्रतिस्थापन।
6. सुरक्षा, कोटा और ऑब्जर्वेबिलिटी जोड़ें
प्रत्येक ऑपरेशन टेनेंट, ऑब्जेक्ट परमिशन, सेशन स्टेट और पार्ट रेंज की जाँच करता है। क्रेडेंशियल्स वर्तमान सेशन तक ही सीमित होते हैं और जल्दी समाप्त हो जाते हैं। प्रति टेनेंट सक्रिय सेशन्स, कुल बाइट्स और पार्ट साइज़ को सीमित करें। टेनेंट-आइसोलेटेड अलर्ट्स के साथ सेशन की सफलता, पुनः प्रयास, चेकसम विफलताओं, क्लीनअप में देरी और अनाथ बाइट्स की निगरानी करें।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं POST /uploads के साथ एक सेशन बनाऊँगा, टेनेंट कोटा और ऑब्जेक्ट साइज़ को मान्य करूँगा, और एक रैंडम uploadId, फिक्स्ड पार्ट साइज़, चेकसम एल्गोरिदम और 24 घंटे की एक्सपायरी जारी करूँगा। प्रत्येक पार्ट अपना नंबर, लंबाई और डाइजेस्ट रखता है; (uploadId, partNumber) आइडम्पोटेन्सी की है। समान डाइजेस्ट वाला डुप्लिकेट मौजूदा परिणाम लौटाता है, जबकि एक अलग डाइजेस्ट अस्वीकार कर दिया जाता है। क्लाइंट छूटे हुए पार्ट्स को खोजने के लिए स्टेटस एंडपॉइंट का उपयोग करता है। कम्प्लीशन एक ऑर्डर्ड लिस्ट और पूरी-फ़ाइल का डाइजेस्ट प्रदान करता है; सर्विस नंबरिंग, कुल लंबाई और पार्ट चेकसम को सत्यापित करती है, फिर ऑब्जेक्ट स्टोर के कम्प्लीट ऑपरेशन को कॉल करती है। असेंबली सफल होने के बाद ही यह ऑब्जेक्ट को READY के रूप में चिह्नित करती है। बार-बार कम्प्लीशन वही वर्ज़न लौटाता है; परस्पर विरोधी सूची कुछ भी नहीं बदलती है। कैंसलेशन और एक्सपायरी वर्कर्स अनाथ स्टोरेज शुल्क से बचते हुए, पुनः प्रयासों के साथ अधूरे अपलोड को एबॉर्ट करते हैं। क्रेडेंशियल्स टेनेंट- और सेशन-स्कोप्ड होते हैं, और क्रिएशन, पार्ट और कम्प्लीशन पाथ सभी कोटा, ऑथराइजेशन, रेट लिमिट्स और ऑडिट को लागू करते हैं।"
सामान्य गलतियाँ और सुधार
- अपलोड को एक लंबा रिक्वेस्ट बनाना: एक सेशन और पार्ट्स का उपयोग करें ताकि नेटवर्क विफलता केवल छूटे हुए डेटा को प्रभावित करे।
- केवल अपलोड किए गए बाइट्स को ट्रैक करना: डुप्लिकेट या आउट-ऑफ-ऑर्डर रिप्लेसमेंट को रोकने के लिए पार्ट नंबर, डाइजेस्ट और वर्ज़न को ट्रैक करें।
- कम्प्लीशन से पहले सफलता चिह्नित करना: पहले स्टोरेज पर असेंबल और सत्यापित करें, फिर
READYऑब्जेक्ट प्रकाशित करें। - एक्सपायर्ड-पार्ट की लागत को अनदेखा करना: कैंसलेशन, बैकग्राउंड एबॉर्ट और स्टोरेज लाइफसाइकिल क्लीनअप एक साथ प्रदान करें।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि क्लाइंट एक ही पार्ट को एक साथ (concurrently) अपलोड करता है?
सेशन और पार्ट नंबर द्वारा मेटाडेटा अपडेट्स को सीरियलाइज़ करें या कंडीशनल राइट का उपयोग करें। समान-डाइजेस्ट डुप्लिकेट्स आइडम्पोटेंट सफलता लौटाते हैं; अलग-अलग डाइजेस्ट्स कॉन्फ्लिक्ट लौटाते हैं, और क्लाइंट पुनः प्रयास करने से पहले स्टेटस को रिफ्रेश करता है।
क्या होगा यदि स्टोरेज के वास्तव में पूरा होने के बाद कम्प्लीशन टाइम आउट हो जाए?
एक कम्प्लीशन आइडम्पोटेन्सी की और टारगेट वर्ज़न को सुरक्षित रखें। पुनः प्रयास पर, पहले स्टोरेज और लोकल स्टेट को क्वेरी करें। यदि सूची पूर्ण वर्ज़न से मेल खाती है, तो वह वर्ज़न लौटाएं; यदि अनिश्चित है, तो COMPLETING रखें और अंधे होकर असेंबल करने के बजाय एक वर्कर को समाधान (reconcile) करने दें।
आप किसी एब्यूसिव क्लाइंट को स्टोरेज भरने से कैसे रोकते हैं?
सेशन निर्माण के समय कोटा रिज़र्व करें और प्रति टेनेंट सक्रिय सेशन्स, कुल पार्ट बाइट्स, कॉनकरेंसी और एक्सपायरी को सीमित करें। पार्ट क्रेडेंशियल्स को सेशन और रेंज से बाइंड करें, एक्सपायर्ड सेशन्स को तुरंत एबॉर्ट करें, और असामान्य पुनः प्रयास दरों पर अलर्ट करें।
क्या समान-की वाले ऑब्जेक्ट्स ओवरराइट करने योग्य होने चाहिए?
डिफ़ॉल्ट रूप से एक नया वर्ज़न या कंडीशनल राइट रखें। यदि ओवरराइट आवश्यक है, तो एक टारगेट वर्ज़न या If-Match स्थिति स्वीकार करें और कम्प्लीशन के बाद एटॉमिक रूप से संदर्भ को अपडेट करें, ताकि एक धीमा अपलोड किसी नए ऑब्जेक्ट को ओवरराइट न कर सके।