सिस्टम डिज़ाइन इंटरव्यू: क्लाउड फ़ाइल स्टोरेज और सिंक सेवा डिज़ाइन करें

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

Dropbox या Google Drive जैसी क्लाउड फ़ाइल स्टोरेज और मल्टी-डिवाइस सिंक सेवा डिज़ाइन करें। इसके 50 मिलियन रजिस्टर्ड यूज़र्स और 5 मिलियन डेली एक्टिव यूज़र्स हैं। प्रत्येक यूज़र औसतन 10 GB लॉजिकल डेटा स्टोर करता है। सिस्टम प्रति दिन 100 मिलियन नए फ़ाइल वर्ज़न प्राप्त करता है, जिसमें प्रति वर्ज़न 4 MB नया या बदला हुआ कंटेंट होता है। पीक ट्रैफ़िक दैनिक औसत का पाँच गुना है। एक फ़ाइल 50 GB तक बड़ी हो सकती है, ऑनलाइन डिवाइसों को 5 सेकंड के भीतर क्रिएट्स, अपडेट्स, मूव्स और डिलीट्स दिखाई देने चाहिए, और मेटाडेटा सेवा 99.99% उपलब्धता का लक्ष्य रखती है।

स्केल, लेटेंसी, उपलब्धता और 4 MiB टारगेट चंक साइज़ इंटरव्यू की धारणाएँ हैं, किसी स्टोरेज प्रोडक्ट की सार्वजनिक प्रदर्शन प्रतिबद्धताएँ नहीं। इसके दायरे में अपलोड, डाउनलोड, रिज्यूमेबल ट्रांसफर, वर्ज़न रिकवरी, मल्टी-डिवाइस सिंक, ऑफ़लाइन एडिटिंग, कॉन्फ़्लिक्ट कॉपी, सरल शेयरिंग और डिलीशन शामिल हैं। कैरेक्टर-लेवल कोलाबोरेशन एडिटिंग, सिमेंटिक Office डॉक्यूमेंट मर्जिंग, एक संपूर्ण एंटरप्राइज़ ऑथराइज़ेशन सिस्टम और एक्टिव-एक्टिव क्रॉस-रीजन राइट्स इसके दायरे से बाहर हैं।

2026 में सार्वजनिक सिस्टम डिज़ाइन प्रॉम्प्ट अभी भी लार्ज-फ़ाइल चंकिंग, डेल्टा सिंक, वर्ज़न, ऑफ़लाइन ऑपरेशन्स और कॉन्फ़्लिक्ट्स के बारे में पूछने के लिए Dropbox, Google Drive या एक जेनेरिक फ़ाइल सिंक सेवा का उपयोग करते हैं। आधिकारिक ऑब्जेक्ट-स्टोरेज दस्तावेज़ भी मल्टीपार्ट अपलोड के इंजीनियरिंग महत्व को स्थापित करते हैं: पार्ट्स को समानांतर में अपलोड किया जा सकता है और एक असफल पार्ट को स्वतंत्र रूप से पुनः प्रयास किया जा सकता है, जबकि छोड़े गए (abandoned) पार्ट्स को अबॉर्ट या लाइफ़साइकिल क्लीनअप की आवश्यकता होती है। यह इंटरव्यू कंटेंट ट्रांसफर को नेमस्पेस स्टेट से अलग करने और रिकवरी और डिलीशन के इर्द-गिर्द शुद्धता (correctness) लूप को पूरा करने के बारे में है, न कि किसी एक कंपनी के आंतरिक आर्किटेक्चर को याद करने के बारे में।

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

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

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

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

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

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

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

• क्या सामग्री सिंक्रनाइज़ की जाती है? सामान्य फ़ाइलें और डायरेक्टरीज़; कोई कैरेक्टर-लेवल लाइव कोलाबोरेशन नहीं।
• किस प्रकार की कंसिस्टेंसी की आवश्यकता है? अपलोड करने वाले डिवाइस को रीड-योर-राइट व्यवहार मिलता है; अन्य ऑनलाइन डिवाइस 5 सेकंड के भीतर कन्वर्ज हो जाते हैं।
• इंक्रीमेंटल हिस्ट्री को कितने समय तक बनाए रखा जाता है? 30 दिन मान लें; पुराने कर्सर को डेल्टास फिर से शुरू करने से पहले एक नेमस्पेस स्नैपशॉट की आवश्यकता होती है।
• कन्करेंट एडिट्स को कैसे हैंडल किया जाता है? दिए गए baseVersionId से केवल एक कमिट करंट बनता है; बाद के परिणाम को कॉन्फ़्लिक्ट कॉपी के रूप में बनाए रखा जाता है।
• क्या डिलीशन बाइट्स को तुरंत पुनः प्राप्त (reclaim) कर सकता है? नहीं। एक टॉम्बस्टोन लिखें और इसे ऑफ़लाइन सिंक और रिकवरी के लिए 30 दिनों तक बनाए रखें।
• क्या डीडुप्लिकेशन सभी यूज़र्स में ग्लोबल है? कंटेंट-अस्तित्व के लीक और एन्क्रिप्शन कपलिंग को कम करने के लिए अकाउंट- या टेनेंट-स्कोप वाले डीडुप्लिकेशन को डिफ़ॉल्ट बनाएं।
• दायरे में किस प्रकार की शेयरिंग है? किसी फ़ाइल या डायरेक्टरी के लिए केवल पढ़ने योग्य (read-only) लिंक; जटिल संगठन अनुमतियाँ एक फॉलो-अप हैं।
• एन्क्रिप्शन और दुर्भावनापूर्ण फ़ाइलों को कैसे हैंडल किया जाता है? ट्रांजिट और रेस्ट में एन्क्रिप्शन, अल्पकालिक हस्ताक्षरित (signed) यूआरएल, और एसिंक्रोनस मैलवेयर स्कैनिंग; एंड-टू-एंड एन्क्रिप्शन दायरे से बाहर है।
• रीजन राइट्स को कैसे स्वीकार करते हैं? प्रत्येक नेमस्पेस का एक होम राइट रीजन होता है; ऑब्जेक्ट्स को क्षेत्रों में दोहराया जा सकता है और मेटाडेटा में एसिंक्रोनस डिजास्टर-रिकवरी रेप्लिकेशन होता है।
• क्या इंस्टेंट-अपलोड हिट की गारंटी है? कोई निश्चित डीडुप्लिकेशन अनुपात नहीं माना गया है। यूज़र-विज़िबल साइज़ के आधार पर लॉजिकल कोटा चार्ज करें और फ़िज़िकल बचत को अलग से मापें।

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

\"मैं ऑब्जेक्ट स्टोरेज में लगभग 4 MiB के इम्यूटैबल चंक्स को स्टोर करूँगा और डायरेक्टरीज़, करंट वर्ज़न, मैनिफ़ेस्ट्स, टॉम्बस्टोन्स और ऑर्डर्ड परिवर्तनों को स्ट्रॉन्गली कंसिस्टेंट मेटाडेटा में रखूँगा। क्लाइंट केवल छूटे हुए चंक्स को अपलोड करते हैं, फिर baseVersionId और एक आइडम्पोटेंसी की (idempotency key) के साथ एटॉमिक रूप से कमिट करते हैं। डिवाइस एक कर्सर को बनाए रखते हैं और केवल /changes?cursor= को ट्रिगर करने के लिए नोटिफिकेशन्स का उपयोग करते हैं, इसलिए एक खोई हुई सूचना से डेटा का नुकसान नहीं होता है। एक कन्करेंट ऑफ़लाइन कमिट एक कॉन्फ़्लिक्ट कॉपी को संरक्षित करता है। प्रति दिन 100 मिलियन वर्ज़न पर, पाँच गुना पीक लगभग 6,000 कमिट/सेकंड है, जबकि 400 TB दैनिक इनग्रेस पीक लगभग 25 GB/s है। डिलीट्स टॉम्बस्टोन बनाए रखते हैं, और चंक्स को केवल एक ग्रेस पीरियड और मैनिफ़ेस्ट समाधान (reconciliation) के बाद ही पुनः प्राप्त किया जाता है।\"

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

पाँच इनवेरिएंट्स (नियमों) के साथ शुरुआत करें:

1. एक प्रकाशित वर्ज़न केवल उन चंक्स को संदर्भित करता है जो मौजूद हैं और अखंडता (integrity) जांच पास कर चुके हैं।
2. एक कमिट currentVersionId को केवल तभी बदलता है जब baseVersionId अभी भी वर्तमान वर्ज़न के बराबर हो।
3. परिवर्तन अनुक्रम संख्याएं (sequence numbers) किसी नेमस्पेस के भीतर सख्ती से बढ़ती हैं, और डिवाइस कर्सर केवल आगे बढ़ते हैं।
4. एक डिलीट एक टॉम्बस्टोन लिखता है; सिंक और रिकवरी विंडो के दौरान जिस डेटा को अभी भी संदर्भित किया जा सकता है, उसे भौतिक रूप से हटाया नहीं जाता है।
5. गारबेज कलेक्शन किसी चंक को केवल तभी हटाता है जब ग्रेस पीरियड और मैनिफ़ेस्ट समाधान के बाद भी कोई संदर्भ न दिखे।

चरण एक: क्लाइंट, मेटाडेटा प्लेन और कंटेंट प्लेन को अलग करें।

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

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

चरण दो: डेटा मॉडल को परिभाषित करें।

FileEntry(id, namespaceId, parentId, name, type, currentVersionId, deletedAt)
FileVersion(id, fileId, baseVersionId, size, manifestHash, createdBy, createdAt)
VersionChunk(versionId, ordinal, chunkHash, size)
UploadSession(id, fileId, baseVersionId, state, expiresAt, idempotencyKey)
Change(namespaceId, seq, entityId, operation, versionId, createdAt)

डायरेक्टरी ट्री स्थिर fileId और parentId मानों का उपयोग करता है, इसलिए किसी मूव या रीनेम से कंटेंट कॉपी किए बिना मेटाडेटा बदल जाता है। एक FileVersion इम्यूटैबल होता है, और ऑर्डर्ड VersionChunk पंक्तियाँ इसका मैनिफ़ेस्ट बनाती हैं। manifestHash मैनिफ़ेस्ट को मान्य करता है लेकिन प्रत्येक चंक के चेकसम को प्रतिस्थापित नहीं करता है। UploadSession सत्र स्थिति और इसकी आइडम्पोटेंसी की को संग्रहीत करता है। Change.seq एक नेमस्पेस के भीतर मोनोटोनिक (एकदिष्ट) है, और डिलीट एक अन्य लॉग किया गया ऑपरेशन है।

(namespaceId, parentId, normalizedName) पर एक कंडीशनल कंस्ट्रेंट के साथ नाम की विशिष्टता लागू करें। उत्पाद को स्पष्ट रूप से केस नॉर्मलाइज़ेशन को परिभाषित करना चाहिए; अन्यथा Windows, macOS और Linux क्लाइंट इस बात पर असहमत हो सकते हैं कि दो नाम परस्पर विरोधी हैं या नहीं।

चरण तीन: रिज्यूमेबल मल्टीपार्ट अपलोड डिज़ाइन करें।

POST /files/{fileId}/upload-sessions
  { baseVersionId, size, chunks[], idempotencyKey }
  -> { uploadSessionId, missingChunks[], signedUrls[] }

PUT {signedChunkUrl}
  Content-Checksum: ...

POST /upload-sessions/{uploadSessionId}/commit
  { manifestHash, idempotencyKey }
  -> { fileVersionId, changeSeq }

GET /files/{fileId}/download-manifest
  -> { fileVersionId, chunks[], signedUrls[] }

क्लाइंट लगभग 4 MiB के चंक्स से शुरू करता है और एक स्ट्रॉन्ग हैश की गणना करता है। सर्वर केवल अकाउंट या टेनेंट के भीतर मौजूदा चंक्स की तलाश करता है और छूटे हुए चंक्स के लिए अल्पकालिक, ऑब्जेक्ट- और ऑपरेशन-स्कोप वाले हस्ताक्षरित (signed) यूआरएल जारी करता है। क्लाइंट सीमित समानता (bounded parallelism) के साथ अपलोड करता है और केवल विफल भागों का पुनः प्रयास करता है। आधिकारिक AWS और Alibaba Cloud मल्टीपार्ट दस्तावेज़ दोनों एक इनिशियेट, अपलोड-पार्ट्स और कम्प्लीट सेशन मॉडल का उपयोग करते हैं। वे यह भी नोट करते हैं कि अधूरे पार्ट्स स्टोरेज का उपभोग करना जारी रखते हैं, इसलिए सत्रों को एक्सपायरेशन की आवश्यकता होती है और लंबे समय से छोड़े गए अपलोड को स्पष्ट रूप से निरस्त (abort) करने की आवश्यकता होती है।

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

चरण चार: वर्ज़न कमिट को एकमात्र पब्लिकेशन बाउंड्री बनाएं।

कमिट एंडपॉइंट पहले idempotencyKey द्वारा मौजूदा परिणाम की खोज करता है, फिर चंक साइज़, हैश, ऑथराइजेशन और कोटा को मान्य करता है। एक मेटाडेटा ट्रांज़ैक्शन में, यह:

1. FileEntry.currentVersionId को लॉक करता है या सशर्त रूप से पढ़ता है।
2. पुष्टि करता है कि यह अभी भी अनुरोध के baseVersionId के बराबर है।
3. इम्यूटैबल FileVersion और VersionChunk मैनिफ़ेस्ट लिखता है।
4. currentVersionId को अपडेट करता है।
5. अगला Change.seq और एक ट्रांज़ैक्शनल आउटबॉक्स रिकॉर्ड जोड़ता है।

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

चरण पांच: कर्सर के साथ डिवाइसों को सिंक्रनाइज़ करें।

GET /changes?namespaceId={id}&cursor={lastSeq}&limit=1000
  -> { changes[], nextCursor, hasMore }

एक डिवाइस उसी ड्यूरेबल ट्रांज़ैक्शन में lastSeq और अपने स्थानीय फ़ाइल इंडेक्स को स्टोर करता है। एक \"नेमस्पेस बदल गया हो सकता है\" नोटिफिकेशन के बाद, यह तब तक खींचता है जब तक कि hasMore=false न आ जाए, क्रिएट्स, अपडेट्स, मूव्स और टॉम्बस्टोन्स को क्रम से लागू करता है, और केवल तभी नया कर्सर कमिट करता है। seq रीप्ले को आइडम्पोटेंट बनाता है। रीऑर्डर किए गए नोटिफिकेशन पुल परिणाम को प्रभावित नहीं करते हैं। यदि प्रत्येक नोटिफिकेशन खो जाता है, तो फ़ोरग्राउंड वेकअप और आवधिक जांच अभी भी एक नए अनुक्रम की खोज कर लेते हैं।

यदि कर्सर 30-दिन की अवधारण (retention) विंडो से पुराना है, तो सेवा एक कंसिस्टेंट नेमस्पेस स्नैपशॉट के स्थान के साथ cursor_expired लौटाती है। क्लाइंट स्नैपशॉट लोड करता है, स्थानीय अनकमिटेड ऑपरेशन्स का समाधान करता है, और स्नैपशॉट वॉटरमार्क से फिर से शुरू करता है। इसे केवल सभी स्थानीय फ़ाइलों को हटाना नहीं चाहिए। नोटिफिकेशन लेटेंसी ऑप्टिमाइज़ेशन हैं; कर्सर लॉग वास्तविक सिंक प्रोटोकॉल है।

चरण छह: कॉन्फ़्लिक्ट्स, विलोपन और वर्ज़न रिकवरी को संभालें।

डिवाइस A और B दोनों ऑफ़लाइन वर्ज़न 10 को संपादित करते हैं। A, baseVersionId=10 के साथ वर्ज़न 11 कमिट करता है। B का बाद का कंडीशनल कमिट विफल हो जाता है। सेवा B के अपलोड किए गए कंटेंट को बरकरार रखती है, \"name (B's conflicted copy)\" या एक कॉन्फ़्लिक्ट वर्ज़न जैसी एक नई प्रविष्टि बनाती है, और एक नेमस्पेस परिवर्तन जोड़ती है। सामान्य बाइनरी फ़ाइलें चुपचाप ऑटो-मर्ज नहीं होती हैं। टेक्स्ट- या दस्तावेज़-विशिष्ट मर्जिंग एक अलग उत्पाद क्षमता है।

एक डिलीट deletedAt को अपडेट करता है और एक टॉम्बस्टोन जोड़ता है। ऑनलाइन डिवाइस प्रविष्टि को ट्रैश में ले जाते हैं, और एक ऑफ़लाइन डिवाइस फिर से कनेक्ट होने पर डिलीट के बारे में जान सकता है। 30-दिन की रिकवरी विंडो के दौरान ऐतिहासिक वर्ज़न और चंक संदर्भ मान्य रहते हैं। इसके बाद, कलेक्टर रिटेन किए गए मैनिफ़ेस्ट्स द्वारा संदर्भित चंक्स के सेट की गणना करता है, असंदर्भित (unreferenced) उम्मीदवारों को चिह्नित करता है, एक ग्रेस पीरियड की प्रतीक्षा करता है, और हटाने से पहले फिर से समाधान करता है। पुनः प्रयास, विलंबित इवेंट्स और रिपेयर जॉब्स एक तात्कालिक संदर्भ गणना को गलत बना सकते हैं, इसलिए यह अपरिवर्तनीय विलोपन के लिए एकमात्र प्राधिकरण नहीं हो सकता है।

चरण सात: क्षमता का अनुमान लगाएं और हॉटस्पॉट को अलग करें।

लॉजिकल स्टोरेज का 50 million × 10 GB = 500 PB। रेप्लिकेशन, हिस्ट्री और डीडुप्लिकेशन भौतिक क्षमता को बदलते हैं, लेकिन प्रॉम्प्ट कोई अनुपात नहीं देता है, इसलिए एक सटीक भौतिक संख्या मनगढ़ंत होगी। दैनिक लॉजिकल इनग्रेस 100 million × 4 MB = 400 TB है, जो औसतन लगभग 4.6 GB/s और पीक पर लगभग 25 GB/s है। वर्ज़न कमिट औसतन 100,000,000 / 86,400 ≈ 1,157/s होते हैं और पाँच गुना पीक पर लगभग 6,000/s तक पहुँचते हैं।

यदि प्रत्येक परिवर्तन औसतन तीन ऑनलाइन डिवाइसों को संकेत देता है, तो सूचनाएं 18,000/s के करीब पीक पर हो सकती हैं। नोटिफिकेशन्स को विश्वसनीय प्रति-फ़ाइल संदेश होने के बजाय \"यह नेमस्पेस बदल गया है\" में समाहित (coalesce) किया जा सकता है। मेटाडेटा को namespaceId द्वारा हैश-शार्ड करें, जिससे एक नेमस्पेस के लिए ऑर्डर्ड राइट्स एक प्राइमरी शार्ड पर रहें। एक बहुत बड़ा साझा स्थान हॉट हो सकता है। बल्क डायरेक्टरी ऑपरेशन्स को रेट-लिमिट करें, नोटिफिकेशन्स को समूहित करें, और सबूत होने पर ही fileId द्वारा फ़ाइल रिकॉर्ड्स को सब-शार्ड करें, जबकि एक अलग नेमस्पेस अनुक्रम जनरेटर बनाए रखें।

चरण आठ: विफलता, सुरक्षा और सत्यापन लूप को बंद करें।

• बाधित अपलोड: सत्र को क्वेरी करें और केवल छूटे हुए भागों को अपलोड करें; लाइफ़साइकिल प्रोसेसिंग छोड़े गए सत्रों को समाप्त कर देती है।
• पार्ट्स अपलोड हो गए लेकिन कमिट विफल रहा: पार्ट्स अस्थायी अनाथ हैं और मैनिफ़ेस्ट समाधान ग्रेस पीरियड के बाद उन्हें पुनः प्राप्त कर लेता है।
• कमिट सफल रहा लेकिन नोटिफिकेशन विफल रहा: ट्रांज़ैक्शनल आउटबॉक्स पुनः प्रयास करता है, और कर्सर पुल अभी भी रिकवर होते हैं।
• कमिट सफल रहा लेकिन प्रतिक्रिया खो गई: वही आइडम्पोटेंसी की मूल परिणाम लौटाती है।
• समवर्ती ऑफ़लाइन राइट्स: baseVersionId स्थिति विफल हो जाती है और सेवा एक कॉन्फ़्लिक्ट कॉपी को सुरक्षित रखती है।
• भ्रष्ट चंक: अपलोड और डाउनलोड एक मजबूत हैश को सत्यापित करते हैं, और अमान्य सामग्री प्रकाशित मैनिफ़ेस्ट में प्रवेश नहीं कर सकती है।
• एक्सपायर हो चुका कर्सर: एक स्नैपशॉट लोड करें, फिर उसके वॉटरमार्क से फिर से शुरू करें।
• होम रीजन राइट नहीं कर सकता: राइट्स रोकें या स्पष्ट RPO/RTO प्रक्रिया के तहत फ़ेलओवर करें; कभी भी दो होम राइटर्स की अनुमति न दें।

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

सत्यापन में 50 GB फ़ाइल का रिज्यूमेबल ट्रांसफर, प्रत्येक अपलोड चरण के बाद क्रैश, डुप्लिकेट कमिट, खोए और रीऑर्डर किए गए नोटिफिकेशन, समवर्ती ऑफ़लाइन संपादन, डिलीट के बाद लौटने वाला पुराना डिवाइस, चेकसम भ्रष्टाचार, प्राइमरी-शार्ड फ़ेलओवर, एक्सपायर हो चुके कर्सर, कोटा सीमाएं और झूठे विलोपन के खिलाफ जीसी सुरक्षा शामिल है। सबसे महत्वपूर्ण एंड-टू-एंड दावा यह है कि प्रत्येक दृश्यমান fileVersionId पूर्ण, सत्यापित कंटेंट में डाउनलोड होता है, और रिकवरी विंडो के अंदर का कोई वर्ज़न कभी भी रिक्लेम नहीं किया जाता है।

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

\"मैं सबसे पहले कंटेंट प्लेन को मेटाडेटा प्लेन से अलग करूँगा। फ़ाइलों को ऑब्जेक्ट स्टोरेज में लगभग 4 MiB के इम्यूटैबल चंक्स में विभाजित किया जाता है। डायरेक्टरीज़, स्थिर fileId मान, करंट वर्ज़न, वर्ज़न मैनिफ़ेस्ट, टॉम्बस्टोन्स और नेमस्पेस सीक्वेंस नंबर एक मेटाडेटा लेयर में रहते हैं जो कंडीशनल राइट्स का समर्थन करती है। मूव्स और रीनेम्स इतिहास को अधिलेखित किए बिना मेटाडेटा को अपडेट करते हैं।

अपलोड के दौरान, क्लाइंट चंक्स को हैश करता है और baseVersionId और एक आइडम्पोटेंसी की के साथ एक सत्र बनाता है। सर्वर केवल टेनेंट-स्कोप वाले छूटे हुए चंक्स के लिए अल्पकालिक हस्ताक्षरित यूआरएल लौटाता है। सभी चंक्स के अपलोड और सत्यापित होने के बाद, एक मेटाडेटा ट्रांज़ैक्शन पुष्टि करता है कि वर्तमान वर्ज़न नहीं बदला है, नया वर्ज़न और मैनिफ़ेस्ट लिखता है, currentVersionId को अपडेट करता है, और Change.seq के साथ एक आउटबॉक्स रिकॉर्ड जोड़ता है। मेटाडेटा प्रकाशन से पहले कंटेंट पूरा हो जाता है, इसलिए एक दृश्यमान वर्ज़न कभी भी लापता बाइट्स को इंगित नहीं करता है। एक खोई हुई प्रतिक्रिया उसी आइडम्पोटेंसी की के साथ पुनर्प्राप्त की जाती है।

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

क्षमता 500 PB लॉजिकल स्टोरेज है। नई या बदली हुई सामग्री 400 TB प्रति दिन है, जो औसतन लगभग 4.6 GB/s और पीक पर लगभग 25 GB/s है। एक सौ मिलियन वर्ज़न औसतन लगभग 1,157 कमिट प्रति सेकंड होते हैं और 6,000/s के करीब पीक होते हैं। मेटाडेटा को एक होम राइट रीजन के साथ नेमस्पेस द्वारा शार्ड किया जाता है, जबकि डाउनलोड सीडीएन और क्षेत्रीय ऑब्जेक्ट रेप्लिका के माध्यम से स्केल होते हैं।

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

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

• मेटाडेटा डेटाबेस में फ़ाइल बाइट्स स्टोर करना → बड़े ऑब्जेक्ट्स रेप्लिकेशन, बैकअप और ट्रांज़ैक्शन पर बोझ डालते हैं → मेटाडेटा में रेफरेंस और ऑब्जेक्ट स्टोरेज में इम्यूटैबल कंटेंट स्टोर करें।
• पहले भाग के अपलोड होने के बाद फ़ाइल प्रकाशित करना → अन्य डिवाइस एक अधूरा वर्ज़न पढ़ सकते हैं → हर भाग के सत्यापित होने के बाद ही मेटाडेटा को एटॉमिक रूप से कमिट करें।
• WebSocket नोटिफिकेशन्स को सिंक ट्रुथ मानना → खोया हुआ संदेश या ऑफ़लाइन अवधि स्थायी रूप से परिवर्तनों को छोड़ देती है → केवल आधिकारिक कर्सर पुल को ट्रिगर करने के लिए नोटिफिकेशन्स का उपयोग करें।
• baseVersionId के बिना कमिट करना → एक ऑफ़लाइन डिवाइस चुपचाप एक नए वर्ज़न को अधिलेखित कर देता है → कंडीशनल कमिट का उपयोग करें और विफलता पर एक कॉन्फ़्लिक्ट कॉपी को सुरक्षित रखें।
• प्रत्येक पुनः प्रयास पर एक नया सत्र और आइडम्पोटेंसी की उत्पन्न करना → डुप्लिकेट वर्ज़न, कोटा शुल्क और अनाथ बढ़ते हैं → मूल परिणाम को पुनर्प्राप्त करने के लिए एक स्थिर की का उपयोग करें।
• वैश्विक क्रॉस-यूज़र इंस्टेंट अपलोड को डिफ़ॉल्ट बनाना → कंटेंट के अस्तित्व का खुलासा होता है और एन्क्रिप्शन/विलोपन युग्मित हो जाते हैं → डीडुप्लिकेशन को किसी अकाउंट या टेनेंट तक सीमित करें।
• यूज़र द्वारा डिलीट करने के तुरंत बाद चंक्स को हटाना → ऑफ़लाइन सिंक, रिकवरी, या विलंबित ट्रांज़ैक्शन लापता बाइट्स को संदर्भित करते हैं → टॉम्बस्टोन, अवधारण, ग्रेस पीरियड और समाधान का उपयोग करें।
• भौतिक क्षमता के लिए एक निश्चित डीडुप्लिकेशन अनुपात मान लेना → एक अज्ञात वर्कलोड गलत सटीकता पैदा करता है → 500 PB लॉजिकल की रिपोर्ट करें और मापों से भौतिक बचत को कैलिब्रेट करें।
• प्रत्येक फ़ाइल परिवर्तन को प्रत्येक डिवाइस पर मज़बूती से पुश करना → नोटिफिकेशन लागत और पुनः प्रयास स्थिति अनियंत्रित हो जाती है → नेमस्पेस संकेतों को समूहित करें और क्लाइंट्स को डेल्टा खींचने दें।
• एक्टिव-एक्टिव क्रॉस-रीजन मेटाडेटा राइट्स से शुरुआत करना → नाम, मूव और करंट-वर्ज़न कॉन्फ़्लिक्ट्स को कन्वर्ज करना कठिन हो जाता है → पहले प्रति नेमस्पेस एक होम राइटर रखें।

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

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

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

फॉलो-अप दो: डायरेक्टरी मूव्स सिंक ऑर्डरिंग को कैसे बनाए रखते हैं?

एक मूव parentId को अपडेट करता है और मेटाडेटा ट्रांज़ैक्शन में एक नेमस्पेस सीक्वेंस जोड़ता है। क्लाइंट इसे seq द्वारा लागू करते हैं। एक मूव प्रत्येक वंशज (descendant) के लिए पाथ्स को फिर से नहीं लिखता है क्योंकि पाथ्स पैरेंट चेन से प्राप्त होते हैं। एक क्रॉस-नेमस्पेस मूव एक स्थानीय मेटाडेटा अपडेट होने का दिखावा नहीं कर सकता है; इसे पुनः प्रयास करने योग्य कॉपी-एंड-डिलीट वर्कफ़्लो के रूप में मॉडल करें और यूज़र को प्रगतिशील स्थिति (in-progress state) प्रदर्शित करें।

फॉलो-अप तीन: एंड-टू-एंड एन्क्रिप्शन और इंस्टेंट अपलोड एक साथ कैसे मौजूद रह सकते हैं?

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

फॉलो-अप चार: क्या होगा यदि एक विशाल साझा डायरेक्टरी हॉट हो जाए?

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

फॉलो-अप पांच: गारबेज कलेक्शन झूठे विलोपन से कैसे बचता है?

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

फॉलो-अप छह: आप क्रॉस-रीजन डिजास्टर रिकवरी कैसे प्रदान करते हैं?

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

फॉलो-अप सात: आप कैसे साबित करते हैं कि सिंक्रोनाइज़ेशन कभी भी डेटा नहीं छोड़ता है?

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