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