सिस्टम डिजाइन सीखते रहें: निर्माण खंड, अभ्यास का क्रम और यह श्रृंखला

संक्षेप (टीएल;डीआर)

समस्या: सिस्टम डिजाइन अक्सर आपस में असंबंधित केस स्टडी के ढेर की तरह सीखा जाता है। लोग "ट्विटर कैसे काम करता है" रट लेते हैं और फिर सवाल थोड़ा बदलते ही अटक जाते हैं।

रास्ता: पहले प्रक्रिया सीखें (ढांचा, अनुमान, बढ़ाना), फिर निर्माण खंड (बंटवारा, प्रतिकृति, आईडी, दर सीमा), फिर वे जाने-माने उत्पाद डिजाइन जो इन्हें जोड़ते हैं, और आखिर में भारी डेटा वाले बड़े सिस्टम। हर एक का अभ्यास जोर से बोलकर, घड़ी लगाकर, हल पढ़ने से पहले करें।

नतीजा: आप डिजाइन रटना बंद करके वही दर्जन भर विचार नए मेलों में पहचानने लगते हैं। यही चीज इंटरव्यू में और असली आर्किटेक्चर समीक्षाओं में काम आती है।

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

यह लेख नक्शा है: क्या किस क्रम में पढ़ें, किसका अभ्यास करें, और यह श्रृंखला खत्म होने के बाद कहां जाएं।

रास्ते का नक्शा

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

चरण ०: प्रक्रिया

इन्हें सबसे पहले पढ़ें, भले आपने पहले सिस्टम डिजाइन किया हो। बाकी श्रृंखला इन्हीं आदतों को मानकर चलती है।

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

चरण १: निर्माण खंड

इनमें से हर एक इतना छोटा है कि पूरा डिजाइन हो सके, और लगभग हर बड़े डिजाइन के अंदर दिखता है।

लेख	जो विचार साथ ले जाते हैं
कंसिस्टेंट हैशिंग	एक नोड जोड़ने पर कुंजियों का छोटा हिस्सा खिसकना चाहिए, लगभग सब नहीं
वितरित कुंजी-मान स्टोर	कोरम, प्रतिकृति, टकराव संभालना, और एलएसएम स्टोरेज लेखन को सस्ता कैसे बनाता है
अद्वितीय आईडी जनरेटर	बिना केंद्रीय गिनती के क्रमबद्ध आईडी, और घड़ी की गड़बड़ी की कीमत
रेट लिमिटर	एल्गोरिदम के समझौते और साझा भंडार में परमाणु गिनती
यूआरएल शॉर्टनर	कुंजी बनाना, भारी पठन के लिए कैश, और गर्म रास्ते को छोटा रखना

चरण २: उत्पाद डिजाइन

ये निर्माण खंडों को ऐसे सिस्टमों में जोड़ते हैं जिन्हें उपयोगकर्ता सीधे छूते हैं। दिलचस्प हिस्से देरी, फैन-आउट और पहुंच की गारंटी के बारे में हैं।

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

चरण ३: भारी डेटा वाले बड़े सिस्टम

यहां कठिन हिस्सा मात्रा और लागत है: पेटाबाइट, अरबों पन्ने, एक साथ लाखों दर्शक।

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

निर्माण खंड, हर एक एक पंक्ति में

अगर इस श्रृंखला से सिर्फ एक तालिका रखें, तो यही रखें। लगभग हर डिजाइन सवाल इन्हीं का कोई मेल है।

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

ऐसा अभ्यास जो याद रहे

हल पढ़ना सीखने जैसा लगता है। ज्यादातर होता नहीं। जो काम करता है:

१. पहले खुद कोशिश करें। इस श्रृंखला का कोई लेख पढ़ने से पहले ४५ मिनट की घड़ी लगाएं और ढांचे के हिसाब से, जोर से बोलते हुए, कागज पर खुद सिस्टम डिजाइन करें। २. फिर मिलाएं। लेख पढ़ें और वे एक या दो बातें लिख लें जो छूट गईं। वही नोट्स आपकी असली पढ़ाई हैं। ३. एक हफ्ते बाद लौटें। बिना देखे उसी सिस्टम को फिर से शुरू से डिजाइन करें। अगर बिना नोट्स के मुख्य समझौता समझा पाते हैं, तो वह आपका हो गया। ४. एक जरूरत बदलें। किसी डिजाइन को एक मोड़ के साथ दोबारा करें: दुनिया भर के दर्शकों और सख्त निजता वाला यूआरएल शॉर्टनर, शुरू से अंत तक कूटबद्ध चैट, बिना रैंकिंग वाली फीड। इंटरव्यू असल में यही मोड़ देते हैं। ५. किसी और के साथ अभ्यास करें। साथी के साथ नकली इंटरव्यू संवाद की वे कमियां सामने लाते हैं जो अकेले अभ्यास में छिप जाती हैं। बारी-बारी से इंटरव्यू लेने वाले बनें; वह भूमिका सिखाती है कि अच्छा जवाब कैसा सुनाई देता है।

इस श्रृंखला के बाद कहां जाएं

किताबें

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

एक बार पढ़ने लायक शोध पत्र

अमेजन का डायनेमो शोध पत्र (कुंजी-मान स्टोर वाले लेख के पीछे के विचार)।
गूगल के बिगटेबल और मैपरिड्यूस शोध पत्र।
राफ्ट शोध पत्र, सहमति की पढ़ने लायक व्याख्या के लिए।

इंजीनियरिंग ब्लॉग

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

कैसे पहचानें कि आप तैयार हैं

आप इंटरव्यू के लिए, और असली डिजाइन चर्चाओं के लिए, तब तैयार हैं जब:

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

जो बच गया

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

वहां से डिजाइन करना कहीं ज्यादा शांत अनुभव है। चरण ० से शुरू करें।