𝗜𝘀 𝗬𝗼𝘂𝗿 𝗦𝗰𝗮𝗹𝗮𝗯𝗹𝗲 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗮 𝗧𝗶𝗰𝗸𝗶𝗻𝗴 𝗧𝗶𝗺𝗲 𝗕𝗼𝗺𝗯?
कई डेवलपर्स सोचते हैं कि स्केलिंग का मतलब अधिक सर्वर जोड़ना है। वे अधिक उपयोगकर्ताओं को संभालने के लिए क्लाउड-नेटिव टूल्स और डिस्ट्रिब्यूटेड डेटाबेस का उपयोग करते हैं। लेकिन यह अक्सर एक नई समस्या पैदा करता है। आप कोई किला नहीं बना रहे हैं। आप ताश के पत्तों का घर बना रहे हैं।
बिना किसी योजना के हॉरिजॉन्टल स्केलिंग (horizontal scaling) करने से केवल आपके फेलियर डोमेन (failure domains) का विस्तार होता है। यदि आपके सिस्टम में फॉल्ट टॉलरेंस (fault tolerance) की कमी है, तो एक छोटी सी त्रुटि सब कुछ क्रैश कर सकती है।
एक वास्तविक सिस्टम बनाने के लिए आपको दो क्षेत्रों पर ध्यान केंद्रित करना चाहिए:
- फॉल्ट टॉलरेंस (Fault Tolerance) अधिक इंस्टेंस (instances) जोड़ने से सहसंबद्ध विफलताओं (correlated failures) को नहीं रोका जा सकता। आपको विफलताओं को अलग (isolate) करना चाहिए ताकि वे फैल न सकें।
- कई Availability Zones का उपयोग करें।
- दो बड़े इंस्टेंस के बजाय छोटे सर्विस इंस्टेंस का उपयोग करें।
- Raft या Paxos जैसे quorum-based consensus का उपयोग करें। यह split-brain परिदृश्यों को रोकता है जहाँ दो क्षेत्र खुद को लीडर समझने लगते हैं।
- नेटवर्क स्प्लिट के दौरान दोषपूर्ण क्षेत्रों को बंद करने के लिए fencing mechanisms का उपयोग करें।
- डेटा कंसिस्टेंसी (Data Consistency) स्पीड के लिए eventual consistency बेहतरीन है। लेकिन महत्वपूर्ण बिजनेस लॉजिक के लिए यह बहुत खराब है। पेमेंट्स या अकाउंट बैलेंस के लिए, आपको strong consistency की आवश्यकता होती है।
- उन distributed transactions पर भरोसा न करें जो आपके सिस्टम को धीमा कर देते हैं।
- Transactional Outbox Pattern का उपयोग करें।
- अपने मुख्य डेटा और एक "outbox" टास्क को एक ही ट्रांजेक्शन में अपने लोकल डेटाबेस में लिखें।
- उन टास्क को मैसेज क्यू (message queue) में भेजने के लिए एक relayer का उपयोग करें।
- सुनिश्चित करें कि आपकी downstream services idempotent हैं ताकि वे डुप्लिकेट मैसेज को सुरक्षित रूप से संभाल सकें।
वास्तविक स्केलेबिलिटी लचीलेपन (resilience) के बारे में है। यदि आप इन सिद्धांतों की अनदेखी करते हैं, तो आप केवल विफलताओं के लिए एक बड़ा खेल का मैदान बना रहे हैं। आज ही सबसे खराब स्थिति (worst-case scenario) के लिए डिज़ाइन करें।
स्रोत: https://dev.to/prabashanadev/is-your-scalable-backend-a-ticking-time-bomb-6o7