सिस्टम डिज़ाइन इंटरव्यू के लिए एक व्यावहारिक ढाँचा

टीएल;डीआर

समस्या: बड़े पैमाने की वास्तुकला (आर्किटेक्चर) तैयार करने के लिए उपलब्धता, थ्रूपुट और परिचालन जटिलता के बीच संतुलन बनाना आवश्यक है।

मुख्य निष्कर्ष: डर लगे तो भी चलने वाली सिस्टम डिज़ाइन इंटरव्यू चेकलिस्ट: पहले सवाल, फिर डब्बों का प्लान, फिर विस्तार। साधारण भाषा में कदम, नमूना संवाद, और ४५-६० मिनट का समय बजट।

परिणाम: उत्पादन वातावरण में विफलता से निपटने और प्रदर्शन लक्ष्यों को हासिल करने की सटीक रूपरेखा।

कोई यह उम्मीद नहीं करता कि आप ४५ मिनट में गूगल सर्च फिर से बना देंगे। इंटरव्यूअर को परफेक्ट चित्र नहीं चाहिए। वे देखना चाहते हैं कि आप धुँधले सवाल को साफ़ समस्या में कैसे बदलते हैं, विस्तार चमकाने से पहले योजना कैसे बनाते हैं, और क्या आप उन्हें साथी की तरह मानते हैं।

अगर अब भी डर लगे, तो ऐसी तस्वीर लें जो आप पहले से जानते हैं।

डॉक्टर की जाँच: डॉक्टर पूछता है कहाँ दर्द है, कब से है, और आपने क्या आज़माया। उसके बाद ही जाँच या दवा। बिना सवाल के सीधा ऑपरेशन गलत प्रैक्टिस है।

घर की मरम्मत: अच्छा मिस्त्री पहले कमरा नापता है, पूछता है कितने लोग रहते हैं, बजट देखता है, फिर टाइल चुनता है। पहले मिनट में शानदार रसोई बना लेना, और फिर पता चलना कि सिंक के लिए पानी ही नहीं, सबका समय बर्बाद है।

सिस्टम डिज़ाइन इंटरव्यू भी वैसे ही चलता है। "सिस्टम डिज़ाइन" का मतलब सिर्फ इतना है: उत्पाद के टुकड़े एक-दूसरे से कैसे बात करेंगे, ताकि असली यूज़र संभल सकें। पहले सवाल। दूसरे बड़ी शक्ल। तीसरे कठिन विस्तार। यह पोस्ट वही प्रक्रिया है, ताकि घबराया उम्मीदवार कदम-दर-कदम चल सके।

असल में क्या अंक मिलते हैं

इसे खुली समस्या पर छोटी काम-मीटिंग समझें, एक सही जवाब वाले क्विज़ की तरह नहीं।

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

ट्रेड-ऑफ़ मतलब ऐसा चुनाव जहाँ एक चीज़ मिलती है और दूसरी जाती है। उदाहरण: डेटा की कई मशीनों पर नकल पढ़ने को तेज़ कर सकती है, लेकिन सब नकलें एक ही पल में अपडेट न हों।

जल्दी दिखने वाले लाल झंडे:

यह जाने बिना दस डब्बे बनाना कि उत्पाद किसके लिए है
मुख्य यूज़र फ्लो खाली छोड़कर छोटे विस्तार पर चमकाना
आकार प्लान बदल दे तो भी मोटे आँकड़े न देना
क्या टूटेगा यह बताए बिना डिज़ाइन "पूरा" घोषित करना

४५ मिनट के लूप के लिए नरम घड़ी

यह नियम नहीं, गाइड है। इंटरव्यूअर ऊँचे स्तर पर रहना चाहें तो वहीं रहें। अगर वे एक कठिन कोने में खींचें, तो उसी दिन वही काम है।

चरण	मिनट	लक्ष्य
१. साफ़ करना और दायरा बाँधना	३-१०	फीचर, यूज़र, सीमाएँ, क्या नहीं बनाएँगे
२. मोटा आकार (जब मदद करे)	२-५	लोड और स्टोरेज का मोटा क्रम
३. ऊँचा प्लान और सहमति	१०-१५	बड़े डब्बे, मुख्य प्रवाह, सादा समझौता
४. कठिन हिस्सों पर विस्तार	१०-२५	डेटा की शक्ल, गति, फेलियर, असली बाधा
५. समापन	३-५	जोखिम, निगरानी, १० गुना पर क्या टूटे, खुले सवाल

ऊँचा स्तर मतलब बड़े टुकड़ों का नक्शा (क्लाइंट, सर्वर, डेटाबेस, कैश), हर कोड लाइन नहीं। बाधा मतलब ट्रैफिक बढ़ने पर पहले जहाँ दम घुटेगा।

कदम १: आवश्यकताएँ साफ़ करें (डॉक्टर वाले सवाल)

वह उम्मीदवार न बनें जो उत्पाद किसके लिए है जाने बिना पूरी आर्किटेक्चर बोल दे। धीरे चलें। जब इंटरव्यूअर कहे "आप तय करें", अपनी मान्यताएँ ऐसे लिखें जहाँ दोनों देख सकें।

उत्पाद के सवाल (यहीं से शुरू)

१. वर्शन एक में क्या ज़रूरी है? क्या बाद में चल सकता है? २. कौन इस्तेमाल करता है: उपभोक्ता ऐप, कंपनी का औज़ार, या सार्वजनिक एपीआई? ३. ज़्यादा पढ़ना, ज़्यादा लिखना, या मिला-जुला? (पढ़ना मतलब डेटा लाना। लिखना मतलब बनाना या बदलना।) ४. अपडेट तुरंत दिखना चाहिए, या थोड़ी देर ठीक है? ५. मोबाइल, वेब, या दोनों? लॉगिन चाहिए? ६. सिर्फ टेक्स्ट, या तस्वीर और वीडियो भी? ७. इंटरव्यू के लिए एक क्षेत्र, या पहले दिन से दुनिया भर?

गुणवत्ता और स्केल के सवाल

१. रोज़ लगभग कितने सक्रिय यूज़र, और कितनी तेज़ी से बढ़ेंगे? २. औसत लोड बनाम भीड़ के घंटे का शिखर? ३. मुख्य कार्रवाई कितनी तेज़ लगे (मोटा लक्ष्य काफी)? ४. गति और बिल्कुल सही एकरूपता भिड़ें तो इस उत्पाद में क्या जीते? ५. डेटा कितने दिन रखें? निजता नियम (खाता मिटाओ जैसा)? ६. कंपनी के मौजूदा औज़ार मान लें (आम डेटाबेस, कैश, संदेश कतार)?

एपीआई मतलब क्लाइंट बैकएंड को जो अनुरोध भेजता है (जैसे: पोस्ट बनाओ, फ़ीड दिखाओ)। कैश मतलब तेज़ अस्थायी भंडार ताकि हर अनुरोध पर मुख्य डेटाबेस न थपथपाएँ। कतार मतलब वह लाइन जहाँ काम थोड़ी देर बाद हो सकता है (ईमेल भेजना, तस्वीर काटना)।

दायरे की अनुशासन

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

छोटा उदाहरण: "न्यूज़ फ़ीड डिज़ाइन करो"

ऐप: मोबाइल और वेब
वर्शन एक: पोस्ट छापना, दोस्तों की पोस्ट समय के उल्टे क्रम में पढ़ना
रैंकिंग एल्गोरिदम: बाद में, जब तक वे न पूछें
प्रति यूज़र दोस्त: लगभग ५,०००
ट्रैफिक: लगभग १ करोड़ दैनिक सक्रिय यूज़र
मीडिया: तस्वीर और छोटा वीडियो ठीक

इतनी बातचीत ही गलत उत्पाद बनाने से रोक देती है।

कदम २: मोटा क्षमता अनुमान (लिफाफे के पीछे का आकार)

परफेक्ट गणित नहीं चाहिए। विश्वसनीय मोटा क्रम चाहिए, ताकि डिज़ाइन खिलौना न लगे।

क्यूपीएस मतलब प्रति सेकंड कितने अनुरोध। मोटा क्रम मतलब "लगभग १००, लगभग १,००,००० नहीं", वित्त की स्प्रेडशीट नहीं।

ये मोटे औज़ार दिमाग में रखें:

मात्रा	थंब रूल
दिन में सेकंड	लगभग १,००,००० (इंटरव्यू के लिए काफी)
दिन के अनुरोध से औसत क्यूपीएस	लगभग १,००,००० से भाग दें; शिखर अक्सर औसत का २-५ गुना
स्टोरेज	आइटम संख्या × औसत आकार, फिर नकल और इंडेक्स के लिए जगह
बैंडविड्थ	क्यूपीएस × आम जवाब का आकार

शक्ल ज़ोर से बोलें:

1 करोड़ दैनिक सक्रिय यूज़र
मान लें प्रति यूज़र प्रति दिन 5 फ़ीड रीड → 5 करोड़ रीड / दिन
5 करोड़ / 1,00,000 ≈ 500 औसत रीड क्यूपीएस
शिखर शायद 2,000-3,000 रीड क्यूपीएस (एक गुणक चुनें और उसी पर टिके रहें)

मान लें प्रति यूज़र प्रति दिन 1 पोस्ट → 1 करोड़ राइट / दिन ≈ 100 औसत राइट क्यूपीएस

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

पूरा औज़ार सेट के लिए देखें बैक-ऑफ़-द-एन्वेलप अनुमान।

कदम ३: ऊँचा डिज़ाइन और सहमति (मरम्मत का नक्शा)

डब्बे बनाएँ। एक सुखी रास्ता शुरू से अंत तक चलाएँ। इंटरव्यूअर को सह-डिज़ाइनर मानें: छह अलग सेवाएँ गढ़ने से पहले राय के लिए रुकें।

आम बिल्डिंग ब्लॉक (डब्बे का मतलब)

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

लोड बैलेंसर स्वस्थ सर्वरों पर अनुरोध बाँटता है। सीडीएन किनारे पर कैश का जाल है जो स्थिर सामग्री यूज़र के पास से देता है। असिंक मतलब "जल्दी करो, ज़रूरी नहीं कि इसी अनुरोध में"।

कैसे पेश करें

१. रेखा: क्लाइंट → दरवाज़ा → सेवाएँ → डेटा स्टोर। २. दो-तीन महत्वपूर्ण उपयोग: बनाना, मुख्य पढ़ना, शायद मिटाना। ३. कहें कि पढ़ना हावी है या लिखना। ४. एपीआई तभी जब समस्या छोटी हो (यूआरएल छोटा करने वाला, रेट लिमिटर)। "गूगल सर्च डिज़ाइन करो" पर मोटा रहें। ५. पूछें: "क्या यह तय स्केल और फीचर से मेल खाता है?" विस्तार से पहले ठीक करें।

न्यूज़ फ़ीड की शक्ल (सिर्फ ऊँचा स्तर)

छापने का रास्ता: क्लाइंट → एपीआई → पोस्ट मेटाडेटा सहेजें → जॉब जो दोस्तों की फ़ीड अपडेट करे (या गंदा चिह्नित करे)।
पढ़ने का रास्ता: क्लाइंट → एपीआई → तैयार फ़ीड लोड करें (या पढ़ते समय जोड़ें) → कैश या डेटाबेस से पोस्ट भरें → एक पेज लौटाएँ।

दो प्रवाह व्हाइटबोर्ड को ईमानदार रखते हैं। सिर्फ "फ़ीड सेवा" लिखा एक विशाल डब्बा नहीं।

कदम ४: अंक देने वाले हिस्सों पर विस्तार

लक्ष्य, ऊँचा रेखाचित्र और इंटरव्यूअर की राय पहले साझा हो चुकी है। अब नुकीले किनारे चुनें।

समस्या के प्रकार से अच्छे लक्ष्य

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

विस्तार चेकलिस्ट (२-४ चुनें)

१. डेटा मॉडल: मुख्य इकाइयाँ, कुंजी, इंडेक्स, ज़रूरत पर मशीनों में बाँटना। २. एपीआई समझौते: सुरक्षित दोबारा कोशिश (आइडेम्पोटेंसी मतलब दोहराने से दो बार न बने), पेजिंग, गर्म रास्ते पर साफ़ त्रुटियाँ। ३. एकरूपता: पैसा या लॉगिन जहाँ मज़बूत; फ़ीड और काउंटर जहाँ थोड़ी देर ठीक, वहाँ अंततः। ४. कैश: क्या कैश, कितनी देर, कैसे साफ़, खाली होने पर भगदड़ कैसे रोकें। ५. असिंक रास्ते: कतार, दोबारा कोशिश, डेड लेटर (फेल जॉब जिन्हें खास संभाल चाहिए), "कम से कम एक बार" ईमानदार भाषा। ६. बाधाएँ: सबसे गर्म क्यूपीएस, सबसे बड़े ऑब्जेक्ट, एक लीडर की सीमा। ७. फेलियर: सर्वर मरना, नेटवर्क टूटना, कैश खाली, कतार भरना। ८. सुरक्षा (संक्षेप, जब तक न पूछें): लॉगिन, दुरुपयोग सीमा, निजी डेटा की सीमा।

समय नियम: अगर विस्तार इस सवाल के लिए सहीपन या स्केल न बदले, किनारे रखें। कहें कि है, आगे जाने का प्रस्ताव दें, हाँ का इशारा देखें।

कदम ५: परफेक्ट घोषित किए बिना समापन

कभी "और यही पूरा डिज़ाइन है" कहकर न बंद करें। आलोचना की जगह छोड़ें।

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

इंटरव्यूअर उन्हें याद रखते हैं जो अपना डिज़ाइन गिराए बिना उसकी आलोचना कर सकें।

नमूना संवाद (साधारण भाषा)

इंटरव्यूअर: न्यूज़ फ़ीड डिज़ाइन करो।

आप: डब्बे से पहले दायरा चाहिए। सिर्फ मोबाइल या दोनों? वर्शन एक में रैंकिंग, या समय का उल्टा क्रम काफी?

इंटरव्यूअर: दोनों क्लाइंट। वी१ के लिए उल्टा समय क्रम ठीक।

आप: लगभग १ करोड़ दैनिक सक्रिय यूज़र, प्रति यूज़र लगभग ५,००० दोस्त, और पोस्ट में तस्वीर मान रहा हूँ। गलत हो तो सुधारें।

इंटरव्यूअर: ठीक लगता है।

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

इंटरव्यूअर: ठीक।

आप: ऊँचा स्तर: छापने का रास्ता पोस्ट लिखता है, फिर पृष्ठभूमि जॉब दोस्तों की फ़ीड बनाने में मदद करता है। पढ़ने का रास्ता तैयार फ़ीड पेज लाता है और कैश या डेटाबेस से शरीर भरता है। क्या यह तय बात से मेल खाता है?

इंटरव्यूअर: हाँ। करोड़ों फॉलोअर वाले सेलिब्रिटी कैसे?

आप: वही कठिन कोना। आम यूज़र के लिए लिखते समय फ़ीड एंट्री धकेल सकता हूँ। विशाल खातों के लिए पढ़ते समय खींचता हूँ, ताकि एक पोस्ट करोड़ों राइट में न फटे। ट्रेड-ऑफ़: सेलिब्रिटी फ़ीड पढ़ने पर ज़्यादा काम।

इंटरव्यूअर: १० गुना पर पहले क्या फेल?

आप: फ़ीड कैश और फैन-आउट वर्कर। फ़ीड स्टोरेज बाँटूँगा, कतार पर बैकप्रेशर डालूँगा, कतार गहराई और कैश हिट दर देखूँगा। ज़्यादा समय मिले तो मल्टी-रीजन और मज़बूत रैंकिंग।

यही संवाद ढाँचा है। शांत इंजीनियर लगने के लिए परफेक्ट चित्र ज़रूरी नहीं था।

करो / मत करो सूची

करो

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

मत करो

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

दोबारा इस्तेमाल होने वाली इंटरव्यू चेकलिस्ट

नोट्स में कॉपी करें। घबराहट में ऊपर से नीचे चलाएँ।

[ ] समस्या एक वाक्य में दोहराएँ
[ ] सिर्फ वर्शन-एक फीचर
[ ] गैर-कार्यात्मक लक्ष्य (यूज़र, क्यूपीएस, विलंब, एकरूपता)
[ ] स्पष्ट बाहर-दायरा सूची
[ ] मान्यताएँ लिखी और पुष्टि
[ ] मोटा क्षमता (क्यूपीएस, स्टोरेज, बैंडविड्थ) अगर डिज़ाइन बदले
[ ] ऊँचा चित्र: क्लाइंट, दरवाज़ा, सेवा, डेटा, असिंक
[ ] मुख्य उपयोग के सुखी रास्ते चलाएँ
[ ] एपीआई या स्कीमा तभी जब समस्या आकार माँगे
[ ] विस्तार से पहले स्पष्ट सहमति
[ ] विस्तार १: डेटा मॉडल / आईडी / स्टोरेज
[ ] विस्तार २: गर्म रास्ता प्रदर्शन (कैश, फैन-आउट, शार्डिंग)
[ ] विस्तार ३: एकरूपता, फेलियर, या ऑप्स (जो उन्हें चाहिए)
[ ] बाधाएँ और १० गुना बदलाव बताएँ
[ ] निगरानी, रोलआउट, ज्ञात जोखिम
[ ] सार + राय आमंत्रित करें

दोस्त को समझाओ

सिस्टम डिज़ाइन इंटरव्यू "कंपनी के हर सर्वर का चित्र" नहीं है। टाइमर पर छोटी योजना-मीटिंग है।

१. पहले पूछो, डॉक्टर की तरह: कौन इस्तेमाल करता है, वर्शन एक में क्या चाहिए, कितना बड़ा, क्या छोड़ेंगे। २. मोटा नाप ताकि पता चले एक डेटाबेस खिलौना है या असली जोखिम। ३. मरम्मत का नक्शा बनाओ: कुछ बड़े डब्बे और मुख्य यूज़र रास्ते। हाँ लो। ४. कठिन कोनों पर ज़ूम जो इंटरव्यूअर चाहता है: डेटा, गति, फेलियर। ५. ईमानदारी से बंद करो: पहले क्या टूटेगा, कैसे देखोगे, ज़्यादा समय पर क्या करोगे।

उस ढाँचे का अभ्यास तीन अलग समस्याओं पर करें (स्टोरेज, रीयलटाइम चैट, पढ़ने-भारी फ़ीड) जब तक मोड़ अपने आप न लगें। लक्ष्य सुंदर चित्र नहीं। लक्ष्य ऐसी डिज़ाइन बातचीत है जो पहली हफ्ते सीनियर इंजीनियर के साथ शर्म न दिलाए।

अगर और इंटरव्यू सवालों से पहले पूरा विकास-पथ चाहिए, शुरू करें शून्य से लाखों यूज़र तक स्केल से। इस श्रृंखला का अभ्यास क्रम: लर्निंग पाथ।