यह काम किस प्रकार करता है?

सबसे सरल आर्किटेक्चर से शुरुआत करें जो सीमाओं को स्पष्ट रखे

एक नए निवेश प्लेटफॉर्म में एक टीम, एक डिप्लॉयमेंट और एक डेटाबेस होता है। इस चरण में एक वितरित सिस्टम की लागत पूरी तरह से ओवरहेड में जाती है: नेटवर्क कॉल वहां जहां एक फंक्शन कॉल पर्याप्त होता, अंततः स्थिरता वहां जहां एक ट्रांजैक्शन पर्याप्त होता, और एक ऐसा परिचालन भार जिसके लिए किसी के पास स्टाफ नहीं है।

इसलिए डिफ़ॉल्ट कार्यान्वयन मॉड्यूलर है: ऑनबोर्डिंग, ऑफर, निवेश, भुगतान, दस्तावेज़, सर्विसिंग और रिपोर्टिंग एक ही डिप्लॉय करने योग्य सिस्टम के भीतर स्पष्ट सीमाओं के पीछे रहते हैं। इसे मॉड्यूलर बनाने वाली चीज फोल्डर संरचना नहीं है, बल्कि यह तथ्य है कि हर मॉड्यूल का एक अनुबंध है, वह अपना डेटा रखता है, और उसकी अपनी टेस्ट से जांच होती है।

जब कोई ठोस कारण हो तभी एक सेवा को अलग किया जाता है

एक मॉड्यूल एक अलग सेवा तभी बनता है जब उसके लिए एक ठोस कारण हो, और ये कारण व्यावसायिक होते हैं, फैशन आधारित नहीं:

चूंकि सीमाएं और अनुबंध पहले से मौजूद हैं, इसलिए किसी सेवा को अलग करना एक पुनर्लेखन नहीं बल्कि एक योजनाबद्ध कार्रवाई है। यही इसका मतलब है: विकल्प खुला रहता है और सस्ता बना रहता है।

जहां यह उचित है वहां असिंक्रोनस प्रक्रिया

वह काम जिसे उपयोगकर्ता को नहीं रोकना चाहिए — निपटान का मिलान, दस्तावेज़ निर्माण, प्रदाता कॉलबैक, रिपोर्टिंग — कतारों के माध्यम से चलता है। RabbitMQ या Kafka जैसे मैसेज ब्रोकर तभी सामने आते हैं जब थ्रूपुट या एकीकरण टोपोलॉजी इसे उचित ठहराती है, न कि डिफ़ॉल्ट रूप से। PostgreSQL रिकॉर्ड की प्रणाली बना रहता है; Redis का उपयोग वहां किया जाता है जहां वास्तव में तेज़ कैशिंग या समन्वय की आवश्यकता होती है।

हम क्या नहीं करते

हम कोई मोनोलिथ नहीं बेचते, और न ही माइक्रोसर्विसेज़ बेचते हैं। दोनों ही उन सवालों के जवाब हैं जो अभी तक किसी ने पूछे ही नहीं हैं। हम प्लेटफॉर्म को गंभीर दिखाने के लिए एक वितरित सिस्टम भी नहीं बनाते — आर्किटेक्चर थिएटर चलाना महंगा है और उसे सौंपना मुश्किल।

आपका आर्किटेक्चर आपके स्केल, नियामक दायित्वों, एकीकरणों और उसे संचालित करने वाली टीम के आकार के आधार पर चुना जाता है — और इसे इस तरह डिज़ाइन किया गया है कि जब ये चीजें बदलें तो यह भी बदल सके।