टीएल;डीआर
- समस्या: बड़े पैमाने की वास्तुकला (आर्किटेक्चर) तैयार करने के लिए उपलब्धता, थ्रूपुट और परिचालन जटिलता के बीच संतुलन बनाना आवश्यक है।
- मुख्य निष्कर्ष: इंटरव्यू के लिए मोटा क्षमता गणित सीखें: क्यूपीएस, स्टोरेज, बैंडविड्थ और लेटेंसी रोज़मर्रा की उपमाओं, एक धीमा हल उदाहरण, और दोस्त को समझाने वाला सारांश के साथ।
- परिणाम: उत्पादन वातावरण में विफलता से निपटने और प्रदर्शन लक्ष्यों को हासिल करने की सटीक रूपरेखा।
आप करीब ३० दोस्तों की पार्टी होस्ट कर रहे हो। केटरिंग की स्प्रेडशीट नहीं चाहिए। पूछते हो: सच में कितने आएँगे? हर व्यक्ति कितने स्लाइस खाएगा? लोग सोडा ज़्यादा पीते हैं या पानी? इससे पिज़्ज़ा और ड्रिंक्स खरीदते हो। एक-दो पिज़्ज़ा कम-ज़्यादा हो सकते हैं। ठीक है। भूखे ३० वयस्कों के लिए ३ पिज़्ज़ा तबाही है। ४० खरीदना बर्बादी है, पर संभल जाता है।
या साप्ताहिक किराने की सोचो। फ्रिज देखो, अनुमान लगाओ कितने खाने बनाओगे, थोड़ा बफ़र जोड़ो, और निकल जाओ। हर टमाटर नहीं तौलते। तुम क्रम-परिमाण की योजना कर रहे हो ताकि हफ़्ते के बीच खाना खत्म न हो, और गाड़ी सड़ने वाले सामान से न भरे।
बैक-ऑफ़-द-एनवेलप अनुमान वही आदत है, सॉफ़्टवेयर पर लगाई हुई। व्हाइटबोर्ड पर बीस बक्से खींचने से पहले पूछो: प्रति सेकंड कितने अनुरोध आते हैं? कितना डेटा रखते हो? नेटवर्क से निकलने वाले जवाब कितने मोटे हैं? मोटे जवाब डिज़ाइन गढ़ते हैं। लगभग २ गुना गलत अक्सर ठीक। १०० गुना गलत (पीक भूलना, या मेगाबाइट को गीगाबाइट समझना) इंटरव्यूअर को चिढ़ाता है।
यह पोस्ट यह कौशल शून्य से सिखाता है। कोई इंटरव्यू चमक मानकर नहीं। पहले क्यों, फिर रसोई और ट्रैफ़िक की उपमाओं से चार संख्याओं के नाम, फिर एक फ़ोटो ऐप उदाहरण धीरे-धीरे, अंकगणित लिखा हुआ, और अंत में "दोस्त को समझाओ" वाला छोटा सारांश।
किसी सूत्र से पहले मोटा गणित क्यों मायने रखता है
सिस्टम डिज़ाइन इंटरव्यू में कमरा लंबा भाग नहीं जाँचता। कमरा देखता है:
१. क्या स्केल आर्किटेक्चर गढ़ने देता हो? ५० अनुरोध प्रति सेकंड वाला फ़ीड और ५०,००० वाला फ़ीड अलग प्रोडक्ट हैं, भले दोनों "टाइमलाइन" हों। २. क्या औसत और पीक अलग रखते हो? लंच का घंटा और लॉन्च दिन दैनिक औसत नहीं हैं। ३. क्या इकाइयाँ ईमानदार रखते हो? "लगभग ५" बेकार है। "लगभग ५ टीबी फ़ोटो प्रति वर्ष" मतलब रखता है। ४. क्या गिनते हुए बोल सकते हो? इंटरव्यू कथन प्लस संख्या है, खामोश कैलकुलेटर काम नहीं।
अनुमान छोड़ो तो अक्सर ओवर-डिज़ाइन (२०० यूज़र वाले टूल पर माइक्रोसर्विस और मल्टी-रीजन) या अंडर-डिज़ाइन (दुनिया की हर फ़ोटो व्यू के लिए एक डेटाबेस) हो जाता है। पाँच मिनट का मोटा गणित दोनों रोकता है।
आप वित्त-ग्रेड क्षमता योजना नहीं बना रहे। मान्यताएँ ज़ोर से बोलो। बेहिचक गोल करो। जब क्रम-परिमाण आर्किटेक्चर दिशा चुनने जितना साफ़ हो, आगे बढ़ो।
चार संख्याएँ, सादे शब्दों में
नाम याद रखो। सूत्र तब आएँगे जब उन्हें महसूस कर सको।
क्यूपीएस (प्रति सेकंड क्वेरी): दरवाज़े पर ट्रैफ़िक
क्यूपीएस बताता है कि सिस्टम एक सेकंड में कितने अनुरोध संभालता है।
रसोई चित्र: फ़ूड ट्रक। अगर एक घंटे में ३,६०० ग्राहक समान रूप से आएँ, तो लगभग १ ग्राहक प्रति सेकंड। अगर कॉन्सर्ट खत्म हो और एक साथ ३० लोग कतार में लगें, तो पीक दर औसत से बहुत ज़्यादा।
ट्रैफ़िक चित्र: टोल बूथ से गुज़रती कारें। दिन भर का औसत शांत। शुक्रवार शाम का पीक ही लेन का आकार तय करता है।
इंटरव्यू में:
- औसत क्यूपीएस = सर्वर, डेटाबेस और रेट लिमिट के लिए आधार लोड।
- पीक क्यूपीएस = जिसके लिए आकार रखते हो (अक्सर औसत का २ से ५ गुना; अपना गुणक ज़ोर से बोलो)।
- रीड क्यूपीएस बनाम राइट क्यूपीएस = अक्सर अलग। सोशल ऐप अक्सर रीड-भारी होते हैं (बहुत व्यू, कम पोस्ट)।
छोटा उदाहरण, लिखा हुआ:
- हर दिन १०,००,००० लोग ऐप इस्तेमाल करते हैं (१एम डीएयू)।
- हर कोई दिन में १ अनुरोध करता है।
- एक दिन में लगभग १,००,००० सेकंड (८६,४०० को गोल करते हैं; आगे)।
- औसत क्यूपीएस ≈ १०,००,००० ÷ १,००,००० = १० क्यूपीएस।
यह छोटा सिस्टम है। १० साधारण क्यूपीएस के लिए विशाल क्लस्टर नहीं चाहिए।
स्टोरेज: रसोई का पेंट्री और गोदाम
स्टोरेज है कि प्रोडक्ट जितना समय डेटा रखना चाहे, उतने के लिए कितनी डिस्क (या ऑब्जेक्ट स्टोरेज) चाहिए।
रसोई चित्र: पेंट्री का आकार पैकेट आकार × कितने पैकेट × बचा खाना कितने दिन रखते हो, पर निर्भर। मसालों का एक जार छोटा। आइसक्रीम से भरा फ्रीज़र नहीं।
सॉफ़्टवेयर में:
- चैट मेटाडेटा की एक पंक्ति कुछ सौ बाइट हो सकती है।
- संपीड़न के बाद फ़ोटो ०.५ एमबी हो सकती है।
- वीडियो सैकड़ों एमबी हो सकता है।
हमेशा मेटाडेटा (छोटी पंक्तियाँ: कौन, कब, शीर्षक) को ब्लॉब (फ़ोटो, वीडियो, फ़ाइल) से अलग रखो। वे अलग सिस्टम में रहते हैं और लागत अलग तरीके से हावी होती है।
बैंडविड्थ: पाइप की चौड़ाई
बैंडविड्थ है कि सेवा में या बाहर प्रति सेकंड (या प्रति दिन) कितना डेटा चलता है।
रसोई चित्र: सिंक नाले की चौड़ाई। पानी की पतली धार ठीक। एक साथ बाल्टी उड़ेलो तो काउंटर डूब जाए।
ट्रैफ़िक चित्र: २ लेन वाली सड़क बनाम ८ लेन। वही "कारें", क्षमता अलग अगर हर कार वीडियो भरा ट्रक हो।
इंटरव्यू में क्लासिक जाँच:
पीक रीड क्यूपीएस × औसत रिस्पॉन्स आकार ≈ पीक बैंडविड्थ
अगर संख्या विशाल हो, अक्सर सीडीएन (यूज़र के पास एज कैश) या छोटे पेलोड चाहिए, बड़ा ऐप सर्वर नहीं।
लेटेंसी: एक ऑर्डर कितना समय लेता है
लेटेंसी है कि एक अनुरोध शुरू से अंत तक कितना इंतज़ार करता है (या सिस्टम के अंदर एक कदम कितना समय लेता है)।
रसोई चित्र: "मैंने ऑर्डर किया" से "प्लेट हाथ में" तक का समय। एक धीमा कदम (ठंडा ओवन, अटका कूरियर) पूरे अनुभव को खराब कर देता है, भले रसोई विशाल हो।
ट्रैफ़िक चित्र: घर से दफ़्तर तक एक कार का समय। और कारें जोड़ना (ज़्यादा क्यूपीएस) उस पुल को नहीं ठीक करता जो हमेशा २ घंटे में पार होता है।
मोटा अंतर्ज्ञान रखो (क्रम-परिमाण; २०२६ हार्डवेयर शीट नहीं):
| काम का प्रकार | मोटा अहसास |
|---|---|
| मेमोरी / कैश से पढ़ना | बहुत तेज़ |
| लोकल एसएसडी से पढ़ना | इंटरव्यू में अभी भी तेज़ |
| स्पिनिंग डिस्क रैंडम सीक | साफ़ धीमा |
| एक डेटा सेंटर के अंदर नेटवर्क | अक्सर १ मिलीसेकंड से नीचे का क्रम |
| महाद्वीपों के बीच नेटवर्क | दसियों से सैकड़ों मिलीसेकंड |
इससे क्या मिलता है: बिना वजह हॉट पथ पर "जवाब से पहले हर इवेंट स्पिनिंग डिस्क पर लिखो" मत रखो। "बस हर जगह रेप्लिकेट" मत बोलो बिना यह कहे कि मल्टी-रीजन लेटेंसी असली है।
दबाव में गढ़ी न जाने वाली इकाइयाँ
सब बाइट से शुरू होता है। लोग केबी, एमबी, जीबी, टीबी मिलाकर अटक जाते हैं।
काम की तालिका (दो की घात, लगभग):
| २ की घात | लगभग | नाम | रोज़ का अहसास |
|---|---|---|---|
| १० | ~१ हज़ार | १ केबी | छोटा टेक्स्ट, आईडी, हेडर |
| २० | ~१ मिलियन | १ एमबी | छोटी फ़ोटो, छोटा क्लिप |
| ३० | ~१ बिलियन | १ जीबी | लैपटॉप रैम स्तर, बड़े दैनिक लॉग |
| ४० | ~१ ट्रिलियन | १ टीबी | बड़ा डेटाबेस या मीडिया टुकड़ा |
| ५० | ~१ क्वाड्रिलियन | १ पीबी | बड़े स्केल पर बहु-वर्ष मीडिया संग्रह |
इंटरव्यू गणित के शॉर्टकट:
- १ दिन = ८६,४०० सेकंड ≈ १,००,००० सेकंड (१०^५)। काफी।
- १ महीना ≈ २.५ मिलियन सेकंड।
- दस लाख यूज़र × दिन में १ कार्रवाई ≈ औसत १० क्यूपीएस (१०,००,००० ÷ १,००,०००)।
शक हो तो आसान दस की घातों की ओर गोल करो। ८६,४०० को १,००,००० बनाओ। बहु-वर्ष स्टोरेज जल्दी चाहिए और सिर्फ़ क्रम-परिमाण चाहिए तो ३६५ दिन को ४०० भी बना सकते हो।
एक मिनट में उपलब्धता ("नाइन")
कभी पूछते हैं सिस्टम कितना डाउन रह सकता है। "नाइन" अपटाइम प्रतिशत हैं:
| उपलब्धता | प्रति वर्ष लगभग डाउनटाइम |
|---|---|
| ९९% (दो नाइन) | लगभग ३.६५ दिन |
| ९९.९% (तीन नाइन) | लगभग ८.८ घंटे |
| ९९.९९% (चार नाइन) | लगभग ५३ मिनट |
| ९९.९९९% (पाँच नाइन) | लगभग ५ मिनट |
रसोई चित्र: कैफ़े जो "साल का ९९% खुला" है, फिर भी कई दिन बंद रहता है। भुगतान सिस्टम अक्सर आंतरिक विकी से ऊँचा लक्ष्य रखता है।
सीनियर दिखने के लिए नाटकीय एसएलए मत गढ़ो। प्रोडक्ट से मेल खाता लक्ष्य चुनो और उसी के लिए डिज़ाइन करो।
क्यूपीएस विधि (बोर्ड पर लिखो)
१. डीएयू (दैनिक सक्रिय यूज़र) लो, या एमएयू (मासिक) से अनुमान लगाओ।
२. गरम एंडपॉइंट पर प्रति यूज़र प्रति दिन कार्रवाई लो (अपलोड, व्यू, पोस्ट)।
३. औसत क्यूपीएस ≈ (डीएयू × प्रति दिन कार्रवाई) / १,००,०००।
४. पीक क्यूपीएस ≈ औसत × पीक गुणक (अक्सर २ से ५ गुना; पूछो या ३ गुना बोलो)।
५. रीड और राइट अलग करो। एक "ट्रैफ़िक" संख्या असली रुकावट छिपाती है।
क्यूपीएस से सर्वर (सिर्फ़ बहुत मोटा समझदारी जाँच):
अगर एक ऐप इंस्टेंस स्वीकार्य लेटेंसी पर लगभग १,००० साधारण क्यूपीएस संभाले (प्रति अनुरोध काम पर बहुत निर्भर):
सर्वर ≈ पीक क्यूपीएस / प्रति इंस्टेंस क्यूपीएस
डिप्लॉय और विफलता के लिए हेडरूम जोड़ो (मान लो २ गुना)। यह खरीद आदेश नहीं। यह जाँच है कि "एक बॉक्स" या "छोटा फ़्लीट" समझदारी भरा है।
स्टोरेज विधि
स्टोरेज ≈ ऑब्जेक्ट आकार × प्रति दिन राइट × रखे गए दिन, फिर रेप्लिका, इंडेक्स और बर्बादी के लिए गुणा।
१. औसत पेलोड आकार (टेक्स्ट, मेटाडेटा, मीडिया)। मीडिया हो तो कैप और औसत अलग। २. डीएयू और क्रिएट दर से प्रति दिन राइट। ३. रिटेंशन (३० दिन? ५ साल? हमेशा?)। ४. गुणक: रेप्लिकेशन (इंटरव्यू में ३ गुना आम), इंडेक्स (कुछ टेबल पर शायद २०% से ५०% अतिरिक्त), लॉग, संस्करण।
मीडिया मौजूद हो तो वही हावी। औसत १ एमबी फ़ोटो, १०,००,००० अपलोड/दिन = थंबनेल और सीडीएन कैश से पहले १ टीबी/दिन। हमेशा मेटाडेटा डेटाबेस आकार को ऑब्जेक्ट स्टोर आकार से अलग रखो।
बैंडविड्थ विधि
१. गरम रीड पथ पर रिस्पॉन्स आकार × क्यूपीएस। २. या सतत राइट इनग्रेस के लिए प्रति दिन लिखे बाइट / १,००,०००। ३. पीक बैंडविड्थ ≈ पीक क्यूपीएस × प्रति रिस्पॉन्स बाइट।
उदाहरण अंश:
- ५०,००० रीड क्यूपीएस
- औसत रिस्पॉन्स २ केबी
५०,००० × २ केबी = १,००,००० केबी/सेकंड = १०० एमबी/सेकंड
१०० एमबी/सेकंड लगभग ०.८ जीबीपीएस है। अकेली यही संख्या बताती है कि एक मशीन का नेटवर्क कार्ड बेतुका है या नहीं, एज सीडीएन चाहिए या नहीं, और छोटे जवाब (पेजिनेशन, कम फ़ील्ड) डिज़ाइन का हिस्सा हैं या नहीं।
हल उदाहरण: फ़ोटो-शेयरिंग ऐप (धीमी चाल)
नकली पर सुसंगत संख्याएँ इस्तेमाल करो। बोलो ये मान्यताएँ हैं। लिख लो।
मान्यताएँ:
- २०० मिलियन मासिक सक्रिय यूज़र (एमएयू)
- आधे किसी दिए दिन ऐप इस्तेमाल करते हैं → १०० मिलियन डीएयू
- प्रत्येक दैनिक यूज़र औसत ०.२ फ़ोटो/दिन अपलोड (लगभग हर ५ दिन में १)
- प्रत्येक दैनिक यूज़र २० फ़ोटो/दिन देखता है
- संग्रहीत औसत फ़ोटो: संपीड़न के बाद ०.५ एमबी
- फ़ीड थंबनेल: २० केबी
- प्रति फ़ोटो मेटाडेटा: २०० बाइट
- मूल ५ साल रखना
- व्यू पर पीक गुणक: ३ गुना
कदम १: राइट क्यूपीएस (अपलोड)
दैनिक अपलोड:
१०,००,००,००० डीएयू × ०.२ फ़ोटो = २,००,००,००० फ़ोटो प्रति दिन
औसत राइट क्यूपीएस (दिन में १,००,००० सेकंड मानकर):
२,००,००,००० ÷ १,००,००० = २०० क्यूपीएस
पीक राइट क्यूपीएस (अगर अपलोड भी ३ गुना पीक मानें, या कम से कम बर्स्ट का ज़िक्र):
२०० × ३ = ६०० क्यूपीएस
सादे शब्दों में मतलब: सामान्य सेकंड में लगभग २०० अपलोड अनुरोध। असली काम है, पर इस प्रोडक्ट की डरावनी संख्या नहीं।
कदम २: रीड क्यूपीएस (व्यू)
दैनिक व्यू:
१०,००,००,००० × २० = २,००,००,००,००० व्यू प्रति दिन
औसत व्यू क्यूपीएस:
२,००,००,००,००० ÷ १,००,००० = २०,००० क्यूपीएस
पीक व्यू क्यूपीएस:
२०,००० × ३ = ६०,००० क्यूपीएस
मतलब: रीड लगभग राइट का १०० गुना (२०,००० बनाम २०० औसत)। स्केल समस्या देखना है, अपलोड नहीं।
कदम ३: ऑब्जेक्ट स्टोरेज (फ़ोटो स्वयं)
दैनिक मीडिया आयतन:
२,००,००,००० फ़ोटो × ०.५ एमबी = १,००,००,००० एमबी प्रति दिन
१,००,००,००० एमबी = १०,००० जीबी = १० टीबी प्रति दिन
पाँच साल (प्रति वर्ष ३६५ दिन):
१० टीबी/दिन × ३६५ दिन/वर्ष × ५ साल
पहले: १० × ३६५ = ३,६५० टीबी प्रति वर्ष
फिर: ३,६५० × ५ = १८,२५० टीबी
१,००० टीबी ≈ १ पीबी, तो १८,२५० टीबी ≈ एक कॉपी के लिए १८ पीबी कच्चा।
अगर टिकाऊपन के लिए ३ कॉपी रखो (सादा इंटरव्यू मॉडल), दसियों पेटाबाइट के क्रम की योजना बनाओ। थंबनेल और ट्रांसकोड और जोड़ते हैं; हर रूप न गिनो, पर ज़िक्र करो।
कदम ४: मेटाडेटा स्टोरेज (हर फ़ोटो की छोटी पंक्तियाँ)
दैनिक मेटाडेटा:
२,००,००,००० × २०० बाइट = ४,००,००,००,००० बाइट
४,००,००,००,००० बाइट = ४ जीबी प्रति दिन (इस मोटे गणित में १ जीबी लगभग १ अरब बाइट)
पाँच साल:
४ जीबी/दिन × ३६५ × ५
४ × ३६५ = १,४६० जीबी प्रति वर्ष
१,४६० × ५ = ७,३०० जीबी ≈ ७.३ टीबी कच्चा
मतलब: मेटाडेटा वर्षों में कुछ टेराबाइट। सामान्य डेटाबेस स्तर में रह सकता है। फ़ोटो बहु-पेटाबाइट समस्या हैं। अलग कामों के लिए अलग स्टोरेज सिस्टम।
कदम ५: बैंडविड्थ अगर हर थंबनेल ऑरिजिन से आए
मान लो हर व्यू तुम्हारे ऑरिजिन से २० केबी थंबनेल खींचे (कोई सीडीएन नहीं):
पीक:
६०,००० क्यूपीएस × २० केबी = १२,००,००० केबी/सेकंड
१२,००,००० केबी/सेकंड = १,२०० एमबी/सेकंड = १.२ जीबी/सेकंड
१.२ जीबी/सेकंड × ८ बिट/बाइट ≈ ९.६ जीबीपीएस, अक्सर लगभग १० जीबीपीएस कहा जाता है।
मतलब: हर गरम छवि ऐप स्तर या ऑरिजिन पथ से परोसना दर्दनाक है। लोकप्रिय छवियों पर सीडीएन + एज कैश का मज़बूत तर्क।
इंटरव्यूअर को क्या कहना है (गणित का उद्देश्य)
"राइट मामूली हैं, औसत लगभग २०० क्यूपीएस। रीड स्केल समस्या हैं, औसत लगभग २०,००० और पीक ६०,०००। पाँच साल का मेटाडेटा सिर्फ़ कुछ टेराबाइट। मूल फ़ोटो बहु-पेटाबाइट। तो डिज़ाइन ऑब्जेक्ट स्टोरेज, गरम मीडिया के लिए सीडीएन, और सादे मेटाडेटा पथ पर केंद्रित है।"
यही अनुच्छेद एनवेलप गणित का कारण है। संख्याओं ने बताया डिज़ाइन समय कहाँ खर्च करना है।
कैश आकार (तेज़ पास)
मोटा इंटरव्यू नियम: पूरा गोदाम नहीं, वर्किंग सेट (गरम डेटा) कैश करो।
रसोई चित्र: आज रात के मसाले काउंटर पर रखो, पूरा सुपरमार्केट रसोई में नहीं।
अगर २०% कुंजियाँ ८०% ट्रैफ़िक लें:
- १ करोड़ सक्रिय ऑब्जेक्ट
- २०% गरम = २० लाख ऑब्जेक्ट
- प्रत्येक २ केबी
२०,००,००० × २ केबी = ४०,००,००० केबी = ४ जीबी उपयोगी कैश, ओवरहेड और रेप्लिका से पहले।
८०/२० मान्यता बोलो। इंटरव्यूअर दूसरा हिट रेट दे तो फिर गिनो।
व्हाइटबोर्ड साफ़ रखने के सुझाव
१. गोल और अनुमान लगाओ। ९९,९८७ ÷ ९.१ असल में "लगभग १,००,००० ÷ १०" है। लंबा भाग कोई नहीं जाँचता। २. मान्यताएँ लिखो। डीएयू, प्रति दिन कार्रवाई, ऑब्जेक्ट आकार, रिटेंशन, पीक गुणक। डिज़ाइन बदले तो लौटो। ३. हर बार इकाई लगाओ। "५" बेकार। "५ एमबी/सेकंड" या "५ टीबी/वर्ष" नहीं। ४. रीड और राइट पथ अलग रखो। एक ट्रैफ़िक संख्या रुकावट छिपाती है। ५. मेटाडेटा और मीडिया अलग रखो। रो स्टोर के बाइट और ऑब्जेक्ट स्टोरेज के बाइट अलग सवालों के जवाब देते हैं। ६. जब सटीकता बेकार हो, बोलो। अगर वैसे भी शार्डिंग चाहिए, १२,४०० बनाम १५,००० क्यूपीएस पर पाँच मिनट मत जलाओ। ७. गणना पेश करो, थोपो नहीं। कुछ पहले आर्किटेक्चर चाहते हैं। पूछो: "गहराई से पहले जल्दी क्षमता जाँच?"
अभ्यास कैसे करें
सूखा अभ्यास तालिकाएँ दोबारा पढ़ने से बेहतर।
१. इकाई तालिका तब तक फ्लैश करो जब तक केबी → एमबी → जीबी → टीबी → पीबी स्वचालित हो। २. एक प्रोडक्ट चुनो (चैट, यूआरएल शॉर्टनर, न्यूज़ फ़ीड, ड्राइव) और टाइमर से १० मिनट में क्यूपीएस + स्टोरेज अनुमान लगाओ। ३. एक मान्यता बदलो (१०× डीएयू, वीडियो जोड़ो, ३०-दिन रिटेंशन) और सिर्फ़ टूटा हुआ फिर गिनो। ४. ज़ोर से समझाओ। इंटरव्यू बोलना प्लस संख्या है। ५. सीखते समय एक पेज चीट शीट रखो, फिर हटा दो। ६. जब संभव हो सार्वजनिक इंजीनियरिंग ब्लॉग से मिलाओ। वही क्रम-परिमाण उनके सटीक आँकड़े से बेहतर।
एक रीड-भारी सिस्टम (न्यूज़ फ़ीड) और एक राइट-भारी पथ (मेट्रिक्स इनजेस्ट, चैट संदेश) दोनों अभ्यास करो ताकि हर बार एक ही साँचा न लगे।
डिज़ाइन इंटरव्यू में यह कहाँ बैठता है
एनवेलप गणित अक्सर छोटा खंड होता है:
१. आवश्यकताएँ और स्केल मान्यताएँ साफ़ करो। २. उच्च-स्तरीय डिज़ाइन। ३. स्केल मामूली न हो तो क्षमता जाँच (यह पोस्ट)। ४. गहराई (एपीआई, डेटा मॉडल, रुकावटें, विफलता मोड)।
अगर संख्याएँ कहें कि एक प्राइमरी डेटाबेस मेटाडेटा संभाले और ऑब्जेक्ट स्टोरेज ब्लॉब संभाले, बोलो और आगे बढ़ो। अगर पीक रीड क्यूपीएस छह अंक हो और हर रीड डिस्क छुए, तो पहले डिज़ाइन ठीक करो, फिर किसी ने न माँगी सुविधाओं के सुंदर बक्से मत खींचो।
जुड़े पोस्ट: रेट लिमिटर डिज़ाइन करें, यूआरएल शॉर्टनर डिज़ाइन करें, रेडिस कैशिंग पैटर्न।
दोस्त को समझाओ
अगर दोस्त पूछे "सिस्टम डिज़ाइन में बैक-ऑफ़-द-एनवेलप अनुमान क्या है?", यह कहो:
"यह सर्वरों के लिए पार्टी प्लानिंग है। अनुमान लगाते हो कितने लोग आएँगे, हर कोई कितना खाएगा, और बचा कितना रहेगा। सॉफ़्टवेयर में ये अनुमान क्यूपीएस (प्रति सेकंड अनुरोध), स्टोरेज (कितना डेटा रखते हो), बैंडविड्थ (पाइप कितनी चौड़ी चाहिए) और लेटेंसी (एक अनुरोध कितना इंतज़ार करता है) कहलाते हैं। कड़ा गोल करते हो, मान्यताएँ बोलते हो, और मोटे जवाबों से आर्किटेक्चर चुनते हो: एक डेटाबेस, कैश, सीडीएन, शार्डिंग, जो संख्याएँ धकेलें। २ गुना गलत होना सामान्य है। इकाइयाँ मिलाना या पीक भूलना असली गलती है।"
फिर एक-पंक्ति सूत्र दो:
| ज़रूरत | मोटा सूत्र |
|---|---|
| सेकंड प्रति दिन | लगभग १,००,००० (१०^५) |
| औसत क्यूपीएस | डीएयू × कार्रवाई/दिन ÷ १,००,००० |
| पीक क्यूपीएस | औसत × २ से ५ (अपना गुणक बोलो) |
| स्टोरेज | आकार × राइट/दिन × रखे दिन × रेप्लिका |
| बैंडविड्थ | क्यूपीएस × प्रति रिस्पॉन्स बाइट |
| कैश | गरम वर्किंग सेट, पूरा डेटासेट नहीं |
बैक-ऑफ़-द-एनवेलप अनुमान संचार का औज़ार है। तुम दिखाते हो कि स्केल सीमाएँ आर्किटेक्चर गढ़ती हैं, और झूठी सटीकता के बिना ईमानदार मोटा गणित हो सकता है। रेसिपी तब तक अभ्यास करो जब तक उबाऊ लगें। घड़ी चल रही हो तो उबाऊ ही चाहिए।