एक खाली लिमिट, दो ऑर्डर: ट्रेडर की क्षमता कैसे बँटती है

ट्रेडर कैपेसिटी की समस्या को अनुरोधों की एक सांकेतिक होड़ से समझते हैं। 14:00:00 पर दो प्रोसेसिंग थ्रेड ने एक ही खाली बैलेंस पढ़ा: 12 000। हर एक को 8 000 का ऑर्डर मिला, उसने «पैसा काफ़ी है» वाली शर्त जाँची और ग्राहक को पेमेंट डिटेल्स दे दिए। अलग-अलग देखें तो दोनों फ़ैसले सही लगते थे। साथ मिलकर उन्होंने 12 000 की उपलब्ध क्षमता पर 16 000 की देनदारियाँ बना दीं।

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

क्षमता कई पाबंदियों से बनती है

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

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

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

Sprut पैनल की सार्वजनिक वीडियो समीक्षा में लेखक न्यूनतम और अधिकतम रक़म, डील काउंटर और अकाउंट की कुल लिमिट अलग-अलग दिखाता है। इस हिस्से में आख़िरी दो की अवधि तय नहीं है। ऐसा प्रदर्शन पैनल के विवरण में अलग सेटिंग होने की पुष्टि करता है, लेकिन बैंक की अनुमति, सर्वर-साइड जाँच की सटीकता या असली थ्रूपुट साबित नहीं करता।

फ़ैसले के साथ ही संसाधन घेरा जाना चाहिए

12 000 वाले उदाहरण में 8 000 के पहले ऑर्डर को रिज़र्वेशन मिलता है, जिसके बाद 4 000 उपलब्ध रहते हैं। दूसरा ऑर्डर नई स्थिति के आधार पर जाँचा जाता है और पास नहीं होता। एटॉमिक रिज़र्वेशन का मतलब यही है: जाँच और स्थिति का बदलाव एक अविभाज्य फ़ैसले के रूप में दर्ज होते हैं। उसके नतीजे में रिज़र्वेशन का आइडेंटिफ़ायर, रक़म, मालिक और वैधता अवधि शामिल होती है।

पेमेंट लेजर यह सुरक्षा अलग-अलग तरीक़ों से लागू करते हैं। उदाहरण के लिए, Modern Treasury का दस्तावेज़ अंतिम बैलेंस या अकाउंट संस्करण की शर्त वाली एंट्री का वर्णन करता है। PostgreSQL प्रतिस्पर्धी बदलावों को नियंत्रित करने के लिए row locks देता है। ये तकनीकी तंत्र हैं, तैयार P2P नीति नहीं: टीम को अभी तय करना है कि कौन-से संसाधन साथ बदलते हैं और किस घटना पर रिज़र्वेशन छूटता है।

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

दोबारा भेजा गया अनुरोध दूसरा हिस्सा न खा जाए

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

असाइनमेंट का अनिश्चित नतीजा ख़ास तौर पर परेशान करता है। निष्पादक तक मैसेज पहुँच गया हो, पर पुष्टि खो गई हो। स्थिति साफ़ होने तक संसाधन को एक साथ दूसरे ऑर्डर के लिए खाली और पहले के लिए घिरा हुआ नहीं माना जा सकता। सिस्टम प्रयास का आइडेंटिफ़ायर सहेजता है, असली स्थिति जाँचता है और एक फ़ैसला करता है। इस जाँच का एक ज़िम्मेदार व्यक्ति और समय-सीमा होनी चाहिए, वरना कतार हमेशा के «लगभग असाइन» से भर जाएगी।

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

स्लॉट खाली हुआ, पर जोखिम बना रहा

मान लीजिए ऑर्डर 14:10 पर एक्सपायर हुआ, रिज़र्वेशन हटा दिया गया, और 14:12 पर बैंक प्राप्ति पकड़ी गई। खाली लिमिट न होने से पैसे की एंट्री ग़ायब नहीं होती। वह एक्सेप्शन में जाती है: स्रोत और उद्देश्य की पुष्टि होती है, देनदारी तय होती है और जोखिम का सही बँटवारा बहाल होता है। फ़ैसले तक इस प्रतिभागी को नए असाइनमेंट रोकने पड़ सकते हैं।

ग़लत रास्ता है देर से आए पैसे को ऑपरेटर की आय मानना या उसे उसी रक़म के अगले ऑर्डर से अपने-आप जोड़ देना। सही रास्ता पेमेंट डिटेल्स के मूल जारी होने से संबंध बनाए रखता है। अगर देर से आने वाली प्राप्तियों के लिए अलग विंडो रखी गई है, तो उसकी लागत पहले से ऑक्यूपेंसी मॉडल में जोड़ी जाती है। वरना लिमिट जल्दी छोड़ने का «ऑप्टिमाइज़ेशन» बस जोखिम को मैन्युअल कतार में छिपा देता है।

डिपॉज़िट गुंजाइश देता है, रफ़्तार टर्नओवर देती है

एक सांकेतिक थ्रूपुट निकालते हैं। 300 000 का उपयोग योग्य कोलैटरल है, सामान्य ऑर्डर 10 000 का है और 12 समानांतर ऑपरेशनल स्लॉट हैं। पुष्टि तक एक ऑर्डर की प्रोसेसिंग में औसतन आठ मिनट लगते हैं। स्लॉट की पाबंदी सैद्धांतिक रूप से प्रति घंटा 90 असाइनमेंट की अनुमति देती है: 12 गुणा 60, भाग आठ। एक जैसी रक़म पर यह बाक़ी पाबंदियों से पहले प्रति घंटा 900 000 का फ़्लो है।

लेकिन अनुबंध के अनुसार कोलैटरल सेटलमेंट तक, औसतन 40 मिनट, रोका जाता है। तब लगातार लोड में 300 000 का कवरेज प्रति घंटा लगभग 450 000 का टर्नओवर संभालता है: 300 000 गुणा 60, भाग 40। ऑपरेशनल स्लॉट ज़्यादा ले सकते थे, लेकिन कोलैटरल धीरे लौटता है। यह स्थिर, एकसमान फ़्लो का अनुमान है, प्रदर्शन का वादा नहीं।

अगर बैंक चैनल की दैनिक अनुमत मात्रा का बाक़ी हिस्सा 1 200 000 है, तो यह रफ़्तार भी उसे लगभग दो घंटे चालीस मिनट में ख़त्म कर देगी। डिपॉज़िट बढ़ाने से बैंक की सीमा नहीं बदलेगी। और सेटलमेंट का समय 80 मिनट हो जाने पर कोलैटरल की पाबंदी अनुमान को प्रति घंटा 225 000 तक गिरा देगी, भले ही जुड़े ट्रेडरों की संख्या वही रहे।

कामकाजी स्क्रीन पर क्या दिखना चाहिए

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

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