हर बड़े पैमाने का ऐप्लिकेशन उन्हीं बुनियादी निर्माण खंडों से मिलकर बनता है। इंटरव्यूअर आपसे नई तकनीक खोजने की उम्मीद नहीं करते। वे देखना चाहते हैं कि आप किसी दी गई समस्या के लिए सही घटकों को चुन और जोड़ सकते हैं या नहीं। यह पाठ उस टूलकिट को कवर करता है जिसका इस्तेमाल आप हर डिज़ाइन इंटरव्यू में करेंगे।
अपने मूल रूप में वेब एक सरल मॉडल का पालन करता है: क्लाइंट अनुरोध भेजते हैं, सर्वर उन्हें प्रोसेस करते हैं, और उत्तर वापस जाते हैं। लेकिन आधुनिक सिस्टम स्केल, विश्वसनीयता और प्रदर्शन संभालने के लिए इन दो एंडपॉइंट के बीच कई परतें जोड़ते हैं।
एक सामान्य अनुरोध इस रास्ते से गुजर सकता है: क्लाइंट → CDN → लोड बैलेंसर → API गेटवे → ऐप्लिकेशन सर्वर → कैश → डेटाबेस। हर परत एक खास समस्या हल करती है, और यह समझना कि कब कौन सी परत चाहिए, मजबूत उम्मीदवारों को औसत उम्मीदवारों से अलग करता है।
इंटरव्यू में, विवरणों में जाने से पहले हमेशा उच्च-स्तरीय क्लाइंट-सर्वर प्रवाह का स्केच बनाकर शुरू करें। इससे संरचित सोच दिखती है।
एक अकेले सर्वर की क्षमता सीमित होती है। लोड बैलेंसर आने वाले अनुरोधों को कई सर्वरों में इन रणनीतियों से बांटते हैं:
लोड बैलेंसर हेल्थ चेक भी करते हैं और खराब सर्वरों को पूल से अपने आप हटा देते हैं। क्लाउड वातावरण में AWS ALB या Azure Front Door जैसी सेवाएं यह काम पारदर्शी तरीके से संभालती हैं।
एक सोशल मीडिया फ़ीड सेवा को लिखने की तुलना में 10 गुना अधिक पढ़ने के अनुरोध मिलते हैं। कौन सा लोड बैलेंसिंग तरीका यह सबसे अच्छी तरह सुनिश्चित करता है कि उपयोगकर्ता लगातार उसी कैश-गरम सर्वर पर पहुंचें?
कैशिंग अक्सर उपयोग किए जाने वाले डेटा को उपभोक्ता के पास रखती है। यह कई स्तरों पर मौजूद होती है:
| परत | उदाहरण | लेटेंसी | |-------|---------|---------| | ब्राउज़र कैश | स्थिर एसेट, API उत्तर | ~0ms | | CDN | इमेज, CSS, JS फ़ाइलें | ~10-50ms | | ऐप्लिकेशन कैश | Redis, Memcached | ~1-5ms | | डेटाबेस कैश | क्वेरी परिणाम कैश | ~5-10ms |
साइन इन करें चर्चा में शामिल होने के लिए
कैश इनवैलिडेशन कंप्यूटिंग की सबसे कठिन समस्याओं में प्रसिद्ध है। सामान्य रणनीतियों में TTL (समय-to-लाइव), लिखाई-through (हर लिखाई पर कैश अपडेट करना), और कैश-aside (ऐप्लिकेशन स्पष्ट रूप से कैश संभालता है) शामिल हैं।
Phil Karlton का प्रसिद्ध कथन, "There are केवल two कठिन चीज़ें in Computer Science: कैश इनवैलिडेशन and नामकरण चीज़ें", इतना व्यापक रूप से उद्धृत है कि सिस्टम डिज़ाइन इंटरव्यू में यह लगभग दीक्षा जैसा बन गया है।
सही डेटाबेस चुनना सबसे प्रभावशाली डिज़ाइन निर्णयों में से एक है:
SQL डेटाबेस (PostgreSQL, MySQL) ACID ट्रांज़ैक्शन, मजबूत कंसिस्टेंसी और संरचित स्कीमा देते हैं। वे तब उत्कृष्ट होते हैं जब डेटा में साफ संबंध हों और आपको जॉइन वाली जटिल क्वेरी चाहिए हों।
NoSQL डेटाबेस कई प्रकार के होते हैं:
आप ऐसा सिस्टम डिज़ाइन कर रहे हैं जो बार-बार बदलने वाले, अर्ध-संरचित डेटा वाले उपयोगकर्ता प्रोफ़ाइल स्टोर करता है (हर उपयोगकर्ता प्रकार के लिए अलग फ़ील्ड)। कौन सा डेटाबेस प्रकार सबसे मजबूत चुनाव है?
हर ऑपरेशन को तुरंत उत्तर की जरूरत नहीं होती। मैसेज क्यू (RabbitMQ, Apache Kafka, AWS SQS) प्रोड्यूसर को कंज़्यूमर से अलग करते हैं, जिससे ये संभव होता है:
Kafka का खास उल्लेख जरूरी है: यह सिर्फ क्यू नहीं बल्कि एक वितरित इवेंट लॉग है, जो इवेंट-ड्रिवन आर्किटेक्चर सक्षम करता है जहां कई कंज़्यूमर इवेंट की उसी स्ट्रीम को स्वतंत्र रूप से प्रोसेस कर सकते हैं।
| पहलू | मोनोलिथ | माइक्रोसर्विस | |--------|----------|---------------| | डिप्लॉयमेंट | एक इकाई | स्वतंत्र सेवाएं | | स्केलिंग | सब कुछ साथ में स्केल करें | अलग-अलग सेवाएं स्केल करें | | जटिलता | शुरू करना सरल | संचालन का अतिरिक्त बोझ | | डेटा | साझा डेटाबेस | हर सेवा का अपना डेटाबेस |
मोनोलिथ से शुरू करें, जरूरत पड़ने पर माइक्रोसर्विस निकालें। अधिकांश इंटरव्यूअर उन उम्मीदवारों की सराहना करते हैं जो मानते हैं कि माइक्रोसर्विस वितरित सिस्टम की जटिलता (नेटवर्क विफलताएं, डेटा कंसिस्टेंसी, डिप्लॉयमेंट ऑर्केस्ट्रेशन) लाते हैं और हमेशा सही चुनाव नहीं होते।
Netflix ने कई वर्षों में मोनोलिथ से माइक्रोसर्विस की ओर माइग्रेट किया था। लेकिन Shopify, जो अरबों के ट्रांज़ैक्शन संभालता है, अभी भी मॉड्यूलर मोनोलिथ चलाता है। किसी दी गई कंपनी के लिए कौन से कारक एक तरीके को दूसरे से बेहतर बना सकते हैं?
CAP थ्योरम कहता है कि कोई वितरित सिस्टम एक साथ केवल तीन में से दो गुणों की गारंटी दे सकता है:
क्योंकि वितरित सिस्टम में नेटवर्क पार्टिशन अनिवार्य हैं, असली चुनाव CP (अवेलेबिलिटी की जगह कंसिस्टेंसी) और AP (कंसिस्टेंसी की जगह अवेलेबिलिटी) के बीच होता है।
आप एक बैंकिंग ट्रांज़ैक्शन सिस्टम डिज़ाइन कर रहे हैं जहां गलत बैलेंस वित्तीय नुकसान करा सकता है। आपको कौन सा CAP समझौता प्राथमिकता देनी चाहिए?
जब आप सिस्टम डिज़ाइन इंटरव्यू में जाएं, तो इस संरचना का पालन करें:
ऐसे सिस्टम के बारे में सोचें जिसे आप रोज़ इस्तेमाल करते हैं, जैसे Instagram, Uber या Spotify. क्या आप पहचान सकते हैं कि यह इस पाठ के कौन से निर्माण खंड संभवतः इस्तेमाल करता है? लोड बैलेंसर कहां होगा? क्या कैश होगा? इसके डेटा मॉडल के लिए कौन सा डेटाबेस प्रकार सही बैठता है?
आगे: हम इन बुनियादी बातों को शुरू से URL शॉर्टनर डिज़ाइन करने में लागू करेंगे।