सिस्टम डिज़ाइन इंटरव्यू: अपने उत्तर की संरचना कैसे करें
अच्छे इंजीनियर सिस्टम डिज़ाइन इंटरव्यू में क्यों असफल होते हैं
आपने वितरित सिस्टम बनाए हैं। आपने प्रोडक्शन आउटेज को डीबग किया है। आप जानते हैं कि CDN क्या है। और फिर भी, जब कोई कहता है "ट्विटर डिज़ाइन करें," आपका दिमाग खाली हो जाता है।
समस्या ज्ञान नहीं है — यह संरचना है। सिस्टम डिज़ाइन प्रश्न जानबूझकर खुले-अंत वाले हैं। एक स्पष्ट फ्रेमवर्क के बिना, आप घटकों के बीच उछलते हैं, आवश्यकताओं को स्पष्ट करना भूल जाते हैं, और महत्वपूर्ण हिस्सों को कवर करने से पहले समय खत्म कर देते हैं।
इंटरव्यू लेने वाले आपके अंतिम आरेख को ग्रेड नहीं कर रहे। वे देख रहे हैं कि आप कैसे सोचते हैं: क्या आप आवश्यकताएँ एकत्र करते हैं, एक डिज़ाइन प्रस्तावित करते हैं, बाधाओं की पहचान करते हैं, और ट्रेडऑफ़ के बारे में तर्क करते हैं? वही सिस्टम डिज़ाइन इंटरव्यू वास्तव में परीक्षण करता है।
किसी भी सिस्टम डिज़ाइन इंटरव्यू के लिए 5-चरणीय फ्रेमवर्क
चरण 1: आवश्यकताओं को स्पष्ट करें (3–5 मिनट)
कुछ भी खींचने से पहले, प्रश्न पूछें। यह एक रोकने की रणनीति नहीं है — यह सबसे महत्वपूर्ण हिस्सा है।
कार्यात्मक आवश्यकताएँ — सिस्टम को क्या करना चाहिए:
- मुख्य उपयोगकर्ता क्रियाएँ क्या हैं? (पोस्ट, पढ़ना, खोज, अनुसरण?)
- कौन से उपयोग के मामले दायरे से बाहर हैं?
गैर-कार्यात्मक आवश्यकताएँ — सिस्टम को कैसे व्यवहार करना चाहिए:
- स्केल: कितने दैनिक सक्रिय उपयोगकर्ता? पढ़ने-भारी या लिखने-भारी?
- विलंबता लक्ष्य: मुख्य उपयोगकर्ता क्रिया के लिए स्वीकार्य क्या है?
- उपलब्धता: अपटाइम SLA क्या है? क्या हम परिनियोजन के दौरान संक्षिप्त डाउनटाइम सहन कर सकते हैं?
- स्थिरता: मज़बूत स्थिरता आवश्यक है, या अंततः स्थिरता ठीक है?
संख्याओं को लिखें। "1M दैनिक उपयोगकर्ता, 100:1 पढ़ने/लिखने अनुपात, पढ़ने के लिए p99 < 200ms" — यह आपके द्वारा लिए गए हर वास्तुशिल्प निर्णय को आकार देता है।
यह कदम न छोड़ें भले ही संकेत स्पष्ट लगे। इंटरव्यू लेने वाले जानबूझकर अस्पष्टता छोड़ते हैं यह देखने के लिए कि क्या आप पूछेंगे।
चरण 2: स्केल का अनुमान लगाएँ (2–3 मिनट)
बैक-ऑफ-द-एनवेलप गणित आपके डिज़ाइन को जमीन देती है। 10M DAU वाले पढ़ने-भारी सिस्टम के लिए:
- प्रति उपयोगकर्ता 50 पढ़ना/दिन मानें → 500M पढ़ना/दिन → ~6,000 पढ़ना/सेकंड
- भंडारण: यदि प्रत्येक रिकॉर्ड 1KB है और आप 10M नए रिकॉर्ड/दिन संग्रहीत करते हैं → 10GB/दिन → 3.6TB/वर्ष
ये संख्याएँ आपको बताती हैं कि क्या आपको एक डेटाबेस या शार्डिंग चाहिए, क्या एक एकल कैश नोड पर्याप्त है, और आपकी CDN रणनीति कैसी दिखनी चाहिए।
चरण 3: उच्च-स्तरीय डिज़ाइन (10–12 मिनट)
अब खींचें। अपनी आवश्यकताओं को संतुष्ट करने वाले सबसे सरल डिज़ाइन से शुरू करें। अधिकांश प्रणालियों के लिए एक अच्छा उच्च-स्तरीय डिज़ाइन शामिल है:
- क्लाइंट → API गेटवे → एप्लिकेशन सेवाएँ
- डेटाबेस — किस प्रकार और क्यों (रिलेशनल, NoSQL, टाइम-सीरीज़)?
- कैश — आप क्या कैश कर रहे हैं और क्यों?
- Async प्रोसेसिंग — एक संदेश कतार कहाँ फिट बैठती है?
- CDN — स्थिर सामग्री या भौगोलिक रूप से वितरित पढ़ने के लिए
उदाहरण के लिए, पैमाने पर एक URL शॉर्टनर:
- लिखने का मार्ग: क्लाइंट → API → एप्लिकेशन सर्वर → DB (छोटा:लंबा मैपिंग लिखें) + कैश
- पढ़ने का मार्ग: क्लाइंट → CDN → लोड बैलेंसर → ऐप सर्वर → कैश (Redis) → कैश मिस पर DB
- छोटा URL उत्पादन: काउंटर-आधारित ID का base-62 एन्कोडिंग के साथ या एक वितरित ID जनरेटर (Snowflake) का उपयोग करें
अपने विकल्प ज़ोर से बताएँ: "मैं यहाँ PostgreSQL का उपयोग कर रहा हूँ क्योंकि डेटा रिलेशनल है और हमें लिखने के लिए मज़बूत स्थिरता चाहिए। पढ़ने के लिए, मैं Redis को सामने रखूँगा।"
चरण 4: गहराई में डुबकी (10–15 मिनट)
उच्च-स्तरीय के बाद, इंटरव्यू लेने वाला आमतौर पर आपको उन क्षेत्रों की ओर ले जाएगा जिनकी वे सबसे अधिक परवाह करते हैं। सामान्य गहराई में डुबकी विषय:
- डेटाबेस स्कीमा डिज़ाइन — आपकी तालिकाएँ, अनुक्रमणिकाएँ, शार्डिंग रणनीति क्या हैं?
- कैशिंग रणनीति — कैश-असाइड बनाम राइट-थ्रू? TTL? कैश अमान्यकरण?
- हॉट स्पॉट को संभालना — जब एक सेलिब्रिटी उपयोगकर्ता के पोस्ट को 10M हिट मिलते हैं तो क्या होता है?
- स्थिरता बनाम उपलब्धता — आप वह ट्रेडऑफ़ स्पष्ट रूप से कहाँ बना रहे हैं?
- डेटा फैन-आउट — सोशल फ़ीड के लिए, आप अनुयायियों को लिखने कैसे प्रसारित करते हैं?
पूछे जाने पर गहराई में जाएँ। इंटरव्यू लेने वाला देखना चाहता है कि आप "डेटाबेस के सामने एक कैश लगाएँ" से "यहाँ निष्कासन नीति है, यहाँ मैं कैश स्टैम्पेड को कैसे संभालता हूँ, यहाँ ट्रेडऑफ़ है जो मैं बना रहा हूँ" तक आगे बढ़ते हैं।
चरण 5: ट्रेडऑफ़ और विकल्प (5 मिनट)
आपने जानबूझकर क्या छोड़ा या सरल बनाया, उसे स्वीकार करके बंद करें। यही अच्छे उम्मीदवारों को महान से अलग करता है।
"मैंने बेहतर लिखने थ्रूपुट पाने के लिए यहाँ अंततः स्थिरता चुनी — लेकिन यदि व्यवसाय को आवश्यकता होती कि हर पढ़ना नवीनतम लिखना दर्शाता, तो मुझे इसे सिंक्रोनस प्रतिकृति के साथ फिर से सोचना पड़ता, जो विलंबता जोड़ती है।"
यह इंजीनियरिंग परिपक्वता का संकेत देता है: आप समझते हैं कि हर वास्तुशिल्प निर्णय एक ट्रेडऑफ़ है, सही उत्तर नहीं।
सामान्य सिस्टम डिज़ाइन इंटरव्यू प्रश्न और वे वास्तव में क्या परीक्षण करते हैं
| प्रश्न | वे वास्तव में क्या परीक्षण करते हैं |
|---|---|
| एक URL शॉर्टनर डिज़ाइन करें | हैशिंग, भंडारण, उच्च पढ़ने थ्रूपुट, कैशिंग |
| ट्विटर/इंस्टाग्राम फ़ीड डिज़ाइन करें | फैन-आउट रणनीतियाँ, अंततः स्थिरता, CDN |
| एक रेट लिमिटर डिज़ाइन करें | टोकन बकेट बनाम लीकी बकेट, वितरित काउंटर |
| एक सूचना प्रणाली डिज़ाइन करें | Async प्रोसेसिंग, संदेश कतारें, रीट्राई तर्क |
| एक वितरित कैश डिज़ाइन करें | सुसंगत हैशिंग, प्रतिकृति, निष्कासन नीतियाँ |
सिस्टम डिज़ाइन इंटरव्यू में सबसे बड़ी गलतियाँ
सीधे कोड या आरेख पर कूदना। हर बार आवश्यकताओं से शुरू करें, भले ही समस्या स्पष्ट लगे।
परिपूर्ण सिस्टम को डिज़ाइन करना। कोई परिपूर्ण सिस्टम नहीं है। इंटरव्यू लेने वाला ट्रेडऑफ़ तर्क चाहता है, एक पाठ्यपुस्तक आरेख नहीं।
मौन हो जाना। अपनी सोच को ज़ोर से सुनाएँ। यदि आप दो दृष्टिकोणों पर विचार कर रहे हैं, तो ऐसा कहें। "मैं X और Y के बीच चुन रहा हूँ — X हमें बेहतर लिखने प्रदर्शन देता है लेकिन Y पढ़ने को स्केल करना आसान है। हमारे 100:1 पढ़ने अनुपात को देखते हुए, मैं Y के साथ जाऊँगा।"
स्केल को अनदेखा करना। हर निर्णय आपकी संख्याओं से वापस जुड़ना चाहिए। "यह 1K QPS पर काम करता है, लेकिन 100K QPS पर हमें शार्ड करना होगा — यहाँ मैं उससे कैसे दृष्टिकोण रखूँगा।"
इसे अभी अभ्यास करें
फ्रेमवर्क जानना और इसे इंटरव्यू लेने वाले के दबाव में लाइव लागू करना दो बहुत अलग चीज़ें हैं।