ट्रेडिंग सिस्टम्स के लिए सॉफ्टवेयर इंजीनियरिंग डिज़ाइन पैटर्न

फाइनेंशियल सॉफ्टवेयर महंगे तरीकों से फेल होता है: डुप्लिकेट ऑर्डर, असंगत बैलेंस, चुपचाप होने वाली पार्शियल फेलियर। डिज़ाइन पैटर्न कोई ट्रॉफी नहीं हैं — ये दोहराई जाने वाली फेलियर स्थितियों के जवाब हैं: ऑडिट-योग्यता के लिए इवेंट सोर्सिंग, रीड को राइट से अलग स्केल करने के लिए CQRS, फैलती हुई आउटेज रोकने के लिए सर्किट ब्रेकर, और यह सुनिश्चित करने के लिए इडेम्पोटेंसी कि रीट्राई से डबल-ट्रेड न हो जाए।

मैचिंग इंजन, रिस्क चेक, और मार्केट-डेटा पब्लिशर को एक बड़े गड्ड-मड्ड ढाँचे में एक-दूसरे को सीधे नहीं बुलाना चाहिए। एक publish/subscribe बस मैचर को fill emit करने देती है, जबकि डाउनस्ट्रीम सर्विसेज़ अपस्ट्रीम की इम्प्लीमेंटेशन डिटेल जाने बिना सब्सक्राइब कर सकती हैं — लेकिन आपको अभी भी डिलीवरी गारंटी (at-least-once बनाम exactly-once) और रीप्ले के लिए रिटेंशन तय करना होगा।

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

ऑर्डर और ट्रांसफर के अपने वैध जीवन-क्रम होते हैं। अनुमत ट्रांज़िशन को एक फाइनाइट स्टेट मशीन में एनकोड करें ताकि अवैध जंप असंभव हो जाएँ। इसे क्लाइंट रिक्वेस्ट पर इडेम्पोटेंसी की के साथ जोड़ें ताकि नेटवर्क रीट्राई से डुप्लिकेट लाइव ऑर्डर न बन सकें।

सेंट्रलाइज़्ड वेन्यू आने वाले ऑर्डर को प्राइस-टाइम प्रायोरिटी के हिसाब से मौजूदा लिक्विडिटी से मैच करते हैं। ऑन-चेन मैचर (जैसे कई L1 DEX डिज़ाइन) निश्चित रूप से डिटरमिनिस्टिक होने चाहिए: हर वैलिडेटर वही क्रम फिर से एग्ज़ीक्यूट करता है और वही state तक पहुँचता है — GaiaEx यह मॉडल Hyperliquid के नियमों से लेता है।

पहले ही दिन हर पैटर्न को बिना सोचे-समझे नकल न करें। साफ़ boundaries, structured logs, और पैसे की आवाजाही के आसपास टेस्ट से शुरुआत करें। जब reconciliation में परेशानी दिखे तो इवेंट लॉग जोड़ें; जब बाहरी API अस्थिर हों तो सर्किट ब्रेकर जोड़ें। पैटर्न असली परेशानियाँ सुलझाते हैं, कल्पित परेशानियाँ नहीं।