संक्षेप (टीएल;डीआर)
- समस्या: सिस्टम डिजाइन इंटरव्यू जानबूझकर खुले छोड़े जाते हैं। मजबूत इंजीनियर इनमें ज्ञान की कमी से नहीं, ढांचे की कमी से असफल होते हैं: वे सीधे बारीकियों में कूद जाते हैं, उन जरूरतों के लिए डिजाइन करते हैं जो किसी ने बताई ही नहीं, और गहराई दिखाने से पहले समय खत्म हो जाता है।
- ढांचा: स्पष्ट करें (५ मिनट), अनुमान लगाएं (५), सहमति के साथ ऊंचे स्तर का डिजाइन (१५), दो या तीन कठिन हिस्सों में गहराई (१५), और समझौतों व अगले कदमों के साथ समापन (५)। अपने फैसलों को तथ्य की तरह नहीं, समझौते की तरह बताएं।
- नतीजा: एक ऐसी बातचीत जिसे इंटरव्यू लेने वाला हर उस पैमाने पर आंक सके जो उसके लिए मायने रखता है: अस्पष्टता संभालना, ठोस डिजाइन, तकनीकी गहराई और संवाद, और साथ में इतना समय कि जहां जरूरी हो वहां गहराई में जा सकें।
"ट्विटर डिजाइन करें" का ४५ मिनट में कोई सही जवाब नहीं होता। इंटरव्यू लेने वाले यह जानते हैं। वे यह आंकते हैं कि आप एक अस्पष्ट सवाल से एक समझदार डिजाइन तक कैसे पहुंचते हैं, और जब वे आप पर दबाव डालते हैं तो आप कैसे सोचते हैं।
यह लेख वह ढांचा है जिसे मैं इस्तेमाल करता हूं और सुझाता हूं। यह कोई पटकथा नहीं है। यह आपके ध्यान का बजट है।
इंटरव्यू लेने वाला असल में क्या आंकता है
हर कंपनी के पैमाने अलग होते हैं, लेकिन वे चार क्षेत्रों में बंट जाते हैं:
| क्षेत्र | अच्छा कैसा दिखता है |
|---|---|
| समस्या को समझना | वे सवाल पूछता है जो डिजाइन बदल दें; समस्या का दायरा सोच-समझकर तय करता है; अपनी मान्यताएं बताता है |
| समाधान का डिजाइन | शुरू से अंत तक एक सुसंगत डिजाइन बनाता है जिसके हर हिस्से के होने की वजह है |
| तकनीकी गहराई | सबसे कठिन हिस्सों में गहराई तक जाता है: डेटा मॉडल, संगति, बढ़ने की अड़चनें, विफलता के तरीके |
| संवाद | जोर से सोचता है, बीच-बीच में पूछता है, संकेत पकड़ता है, समझौतों को सरल शब्दों में समझाता है |
ध्यान दें कि क्या नहीं है: रटे हुए आर्किटेक्चर, चलताऊ शब्द और "सही" डेटाबेस। जो उम्मीदवार असामान्य विकल्प चुनकर उसका समझौता साफ समझाता है, उसे उस उम्मीदवार से बेहतर अंक मिलते हैं जो अपेक्षित विकल्प चुनता है पर बता नहीं पाता कि क्यों।
४५ मिनट का बजट
लाल टिप्पणी सबसे आम विफलता बताती है: सीधे किसी एक हिस्से की अंदरूनी बनावट में कूद जाना और कभी तय ही न करना कि सिस्टम किसलिए है।
कदम १: स्पष्ट करें (० से ५ मिनट)
आपका लक्ष्य जरूरतों की एक छोटी, साफ सूची है जिस पर आप और इंटरव्यू लेने वाला सहमत हों।
कार्य संबंधी सवाल (सिस्टम को क्या करना है?)
- उपयोगकर्ता कौन हैं, और दो या तीन मुख्य काम कौन से हैं?
- आज कौन सी सुविधाएं दायरे में हैं, और किन्हें हम साफ तौर पर बाहर रख सकते हैं?
- कोई खास स्थिति जो डिजाइन बदल दे (निजी खाते, संपादन, हटाना, मीडिया)?
गुणवत्ता संबंधी सवाल (कितनी अच्छी तरह करना है?)
- कितने उपयोगकर्ता, और कितने सक्रिय? ट्रैफिक दुनिया भर से है या किसी एक क्षेत्र से?
- कौन सी देरी मायने रखती है, और किस काम के लिए?
- क्या थोड़ा पुराना डेटा दिखाना चलेगा? क्या कभी कोई लेखन खो सकता है?
- पठन ज्यादा है या लेखन?
फिर सूची वहां लिखें जहां आप दोनों देख सकें। "न्यूज फीड डिजाइन करें" के लिए उदाहरण: पाठ और चित्र पोस्ट करना, उपयोगकर्ताओं को फॉलो करना, फॉलो किए गए खातों की होम फीड देखना, सबसे नया पहले; रोज ३० करोड़ सक्रिय उपयोगकर्ता; फीड २०० मिलीसेकंड से कम में खुले; पोस्ट दिखने में कुछ सेकंड की देरी चलेगी। दायरे से बाहर: विज्ञापन, संदेश, खोज।
वह सूची अगले ४० मिनट के लिए आपका अनुबंध है।
कदम २: अनुमान लगाएं (५ से १० मिनट)
बस उतना गणित करें जितना कठिन हिस्सा ढूंढने के लिए जरूरी है: पठन और लेखन की प्रति सेकंड क्वेरी, स्टोरेज की बढ़त, और कोई भी बैंडविड्थ जो हावी हो सकती है। इस श्रृंखला का अनुमान वाला लेख इसके नुस्खे देता है।
सिर्फ संख्याएं नहीं, निष्कर्ष बोलें: "पठन लेखन से लगभग १०० गुना ज्यादा हैं, और फैन-आउट लेखन को फॉलोअर की संख्या से गुणा कर देता है, इसलिए टाइमलाइन का स्टोरेज और फैन-आउट कठिन हिस्सा हैं।"
कुछ इंटरव्यू लेने वाले कहेंगे कि अनुमान छोड़ दें। फिर भी एक वाक्य में कर लें; निष्कर्ष तब भी आपके डिजाइन को आकार देता है।
कदम ३: ऊंचे स्तर का डिजाइन और सहमति (१० से २५ मिनट)
किसी भी चीज की बारीकी में जाने से पहले हर मुख्य काम का शुरू से अंत तक का प्रवाह बनाएं।
१. पहले एपीआई। मुख्य मानदंडों के साथ दो या तीन एंडपॉइंट: POST /posts, GET /feed?cursor=। ये आपको साफ करने पर मजबूर करते हैं कि हर अनुरोध क्या करता है।
२. डेटा मॉडल। मुख्य इकाइयां, उनकी कुंजियां और उनका बंटवारा। यहीं पर कई डिजाइन चुपचाप सफल या असफल होते हैं।
३. डिब्बे और तीर। क्लाइंट, किनारा (लोड बैलेंसर, सीडीएन), सेवाएं, डेटा भंडार, कतारें। हर मुख्य काम में एक अनुरोध को शुरू से अंत तक चलाकर दिखाएं।
४. पूछें। "क्या यह वह सब ढकता है जो आप चाहते हैं, या गहराई में जाने से पहले कुछ बदलें?" यह सहमति का पल है, और अक्सर इससे संकेत मिल जाता है कि इंटरव्यू लेने वाला गहराई कहां चाहता है।
आम निर्माण खंड और वे अपनी जगह कब कमाते हैं:
| खंड | तब जोड़ें जब |
|---|---|
| लोड बैलेंसर | किसी भी चीज के एक से ज्यादा इंस्टेंस हों |
| कैश | ऐसे डेटा का भारी पठन हो जो थोड़ा पुराना होना सह सके |
| पठन प्रतिकृतियां | पठन का भार एक डेटाबेस से ज्यादा हो जाए |
| संदेश कतार | काम जवाब के बाद हो सकता हो, या उसे दोबारा चलाना पड़े |
| सीडीएन | स्थिर या मीडिया सामग्री बहुत से उपयोगकर्ताओं को परोसी जाए |
| शार्डिंग | सस्ते विकल्पों के बाद भी डेटा या लेखन का भार एक डेटाबेस से ज्यादा हो |
| ऑब्जेक्ट स्टोरेज | बड़ी फाइलें हों: चित्र, वीडियो, दस्तावेज, बैकअप |
हर डिब्बे को इस सवाल का जवाब देना चाहिए: "इसे हटा दूं तो क्या टूटेगा?" अगर जवाब नहीं है, तो उसे हटा दें।
कदम ४: गहराई में जाएं (२५ से ४० मिनट)
इस समस्या के दो या तीन सचमुच कठिन हिस्से चुनें, या इंटरव्यू लेने वाले के इशारे पर चलें। समस्या के प्रकार के हिसाब से अच्छे निशाने:
| समस्या का प्रकार | गहराई कहां है |
|---|---|
| फीड और टाइमलाइन | लेखन पर फैन-आउट बनाम पठन पर, मशहूर हस्तियों की समस्या, रैंकिंग, पेज बांटना |
| चैट और तत्काल संवाद | कनेक्शन संभालना, क्रम, पहुंच की गारंटी, उपस्थिति |
| स्टोरेज सिस्टम | बंटवारा, प्रतिकृति, संगति, टकराव सुलझाना |
| यूआरएल शॉर्टनर, आईडी जनरेटर | कुंजी बनाना, टकराव, गर्म कुंजियां, कैश |
| रेट लिमिटर | एल्गोरिदम का चुनाव, परमाणुता, वितरित गिनती, विफलता पर खुला या बंद |
| मीडिया प्लेटफॉर्म | अपलोड पाइपलाइन, ट्रांसकोडिंग, सीडीएन, लागत |
| खोज और स्वतः पूर्ति | इंडेक्स बनाने की पाइपलाइन, रैंकिंग, देरी का बजट |
हर गहराई वाले हिस्से में ये चार बातें रखें: सीधा-सादा तरीका और वह क्यों विफल होता है, बेहतर तरीका, उसकी कीमत, और वह कैसे विफल होता है। यह चार हिस्सों वाला आकार किसी भी मात्रा की तकनीकी शब्दावली से ज्यादा भरोसे से गहराई दिखाता है।
कदम ५: समापन (४० से ४५ मिनट)
डिजाइन को संपूर्ण घोषित न करें। उसे दो वाक्यों में समेटें, फिर बताएं:
- अभी की सबसे बड़ी अड़चन और उसके भर जाने पर आप क्या करेंगे।
- आपने जो मुख्य समझौता किया और उस पर कब दोबारा सोचेंगे।
- उत्पादन में आप किस चीज पर नजर रखेंगे।
इससे वह विवेक दिखता है जो वरिष्ठ उम्मीदवारों में खोजा जाता है: आप जानते हैं कि आपने क्या बनाया, उसकी कीमत क्या है, और वह सबसे पहले कहां टूटेगा।
एक छोटा नमूना संवाद
इंटरव्यू लेने वाला: एक यूआरएल शॉर्टनर डिजाइन करें।
उम्मीदवार: कुछ भी बनाने से पहले कुछ सवाल। क्या हमें मनचाहे उपनाम और समाप्ति चाहिए, या सिर्फ यादृच्छिक कोड? क्या क्लिक का विश्लेषण चाहिए? हर महीने लगभग कितने लिंक, और पठन व लेखन का कौन सा अनुपात मानूं?
इंटरव्यू लेने वाला: मनचाहे उपनाम हां, विश्लेषण मोटे तौर पर, हर महीने १० करोड़ लिंक, ज्यादातर पठन।
उम्मीदवार: तो मैं रीडायरेक्ट को मुख्य रास्ता मानूंगा और विश्लेषण को जितना हो सके उतना। हर महीने १० करोड़ यानी हर सेकंड लगभग ४० लेखन, और हर लेखन पर १०० पठन के हिसाब से औसतन लगभग ४,००० रीडायरेक्ट प्रति सेकंड। कठिन हिस्से हैं कोड बनाना और रीडायरेक्ट तेज रखना, इसलिए उन्हें मैं ध्यान से डिजाइन करूंगा और विश्लेषण को रीडायरेक्ट के रास्ते से बाहर रखूंगा। ये रहे दो एपीआई...
ध्यान दें कि उम्मीदवार ने कभी "सही" जवाब का दावा नहीं किया। उसने सवाल को जरूरतों में बदला, कठिन हिस्सा बताया, और उसे डिजाइन करने का हक कमाया।
क्या करें और क्या न करें
| करें | न करें |
|---|---|
| जरूरतें लिखें और बार-बार उन पर लौटें | पहले ही मिनट में डिब्बे बनाना शुरू करना |
| कहें "मैं यह मान रहा हूं; गलत हो तो बताइए" | चुपचाप मान लेना और उम्मीद करना |
| हर चुनाव को समझौते की तरह समझाएं | तकनीकों को स्वाभाविक रूप से सही बताना |
| एक अनुरोध को शुरू से अंत तक चलाएं | हिस्सों को अलग-अलग बताना |
| ऊंचे स्तर का डिजाइन पूरा होने पर पूछें | २० मिनट का एकालाप |
| जो नहीं जानते उसे मानें और बुनियादी सिद्धांतों से सोचें | किसी तकनीक की अंदरूनी बनावट पर झांसा देना |
| पूछे जाने से पहले विफलता के तरीके बताएं | मान लेना कि सब ठीक चलेगा |
दोबारा इस्तेमाल लायक जांच सूची
- कार्य संबंधी जरूरतें लिखी और तय; दायरे से बाहर क्या है, बताया
- गुणवत्ता संबंधी जरूरतें: पैमाना, देरी, संगति, उपलब्धता
- कठिन हिस्से के बारे में साफ निष्कर्ष के साथ अनुमान
- एपीआई और मुख्य डेटा मॉडल
- हर मुख्य काम का शुरू से अंत तक प्रवाह
- गहराई से पहले सहमति की जांच
- दो या तीन गहराई वाले हिस्से: सीधा तरीका, बेहतर तरीका, कीमत, विफलता
- समापन: अड़चन, मुख्य समझौता, किस पर नजर रखें
जो बच गया
मुझे जो उम्मीदवार याद हैं, वे सबसे चतुर डिजाइन वाले नहीं हैं। वे हैं जिन्होंने शुरुआत में एक ऐसा सवाल पूछा जो मैंने सोचा ही नहीं था, और फिर अपना पूरा जवाब उसी के इर्द-गिर्द बनाया।
असली काम भी यही है। ज्यादातर असली डिजाइन का काम यह समझना है कि सिस्टम किसलिए है। डिब्बे बाद में आते हैं, और आमतौर पर वे आसान हिस्सा होते हैं।
स्रोत
- एलेक्स शू, सिस्टम डिजाइन इंटरव्यू: एक भीतरी व्यक्ति की मार्गदर्शिका
- मार्टिन क्लेपमैन, डेटा-प्रधान एप्लिकेशन डिजाइन करना
- टेक इंटरव्यू हैंडबुक: सिस्टम डिजाइन इंटरव्यू
- गूगल एसआरई पुस्तक: परिचय (डिजाइन के लक्ष्य के रूप में विश्वसनीयता)
- इसी श्रृंखला में: मोटा अनुमान लगाना, सिस्टम डिजाइन सीखते रहें, न्यूज फीड सिस्टम डिजाइन करें